• weightless

    @rotho In Pd vanilla [text] could do it I think. [text search] is not very versatile but there are workarounds. For example, if you have one line of text for each file, and each field is a fixed tag (first field: filename, second field: key, third field: bpm etc), you can do searches with [text sequence] followed by list split, select etc.
    Hope that makes sense.

    posted in technical issues read more
  • weightless

    @zxcvbs Hi, yes I realise the patch is very counterintuitive, I'll do my best to try and explain what's going on. Let's forget about polyphony and consider one voice.
    The PMops abstraction is the single voice, inside it are the three operators (PMop, both badly named sorry) and the tables subpatch. The basic structure of each operator could be reduced to the simple:
    Screenshot 2019-09-01 at 10.48.46.png
    but the +~ object, instead of receiving the phase from a fixed modulator, it receives it from a table. Each operator has its own table, so operator 1 receives the phase from tabreceive~ $0-phase1 which is connected to +~.
    At the same time (to populate those tables), the output from cos~ of each operator is sent to all tables, how much of the signal goes to each is decided in the modulation matrix.
    The reason I decided for this arrangement is because this way each operator can send its phase to any operator, including itself (feedback). As explained in the first post, feedback has to be done with the operator working at block~ 1 in order to sound good, but if an operator receives the feedback every sample (block~ 1) but to that you add the phase of the other modulators every 64 samples (the default block size), the result sounds bad. This is the reason I used this mess of tables, to have an FM-8 style modulation matrix.
    If you want to implement hard-coded algorithms, the same thing can be done without tables, patching each algorithm in its own abstraction or subpatch and switch between them as @whale-av suggested in your thread. Plus I see none of your algorithms have feedback, so they don't even need to run at block~ 1, and therefore the approach with tables is really not necessary.
    Hope this clarifies things a bit.

    posted in abstract~ read more
  • weightless

    @Revoan Hi, instead of [table notes], you can use [array define -k notes]. The -k flag means that the content of the table is saved with the patch. Alternatively, you can connect a [loadbang] to the message which sends the notes to the table. Loadbang sends a bang as soon as the patch has loaded.

    posted in technical issues read more
  • weightless

    @nickporcaro If it helps, this is a version of [receive] which lets you switch the source using dynamic patching. dreceive.zip

    For me the trickiest part is keeping track of duplicates in the chain. If you are willing to manually specify duplicates in the text (something like: 1-lop~ 400, hip~ 20, 2-lop~ 400 etc) then my patch could be made usable I think, otherwise if we are talking about a chain of hundreds of filters, making a duplicate checker would require some work.
    How many filters are you looking at using?

    posted in patch~ read more
  • weightless

    @nickporcaro Ah yes, of course. Each filter would have to have a unique name otherwise if you have, say, two [lop~ 400] you wouldn't know which is which. If this is a one-off sort of application with just simple filter objects in the chain, you could modify the patch (and the list in text) as to give unique names to double filters, something like [lop~ 400 1], [lop~ 400 2] etc. When you want to move them around you can just cut and paste the corresponding line in text and put it somewhere else (it doesn't matter if lop~ 1 comes after lop~ 2 as they would be the same).
    If you are looking for a more universal method which includes more complicated stuff in the chain, you'd probably have to somehow check upon creation whether the object you are creating already exists. Perhaps DRFX can provide some helpful insights on how to do it, but I haven't checked it out yet.

    posted in patch~ read more
  • weightless

    @nickporcaro As far as I understand it what @whale-av was saying is that you get a click when changing the order. This could be forced to happen between dsp cycles, I think. What do you mean by "depend on the order of catch~ and throw~"?

    posted in patch~ read more
  • weightless

    @nickporcaro Hi, this is something I thought up in response to your question, I haven't actually used it so I'm not sure if it works reliably, but at least it gives you an idea on a possible approach. This method basically uses abstractions and their arguments to create the filter themselves and their respective catch~/throw~ objects, then the order of execution is specified in a text. This way you can save/load different routings to .txt files. signal_order.zip
    It's not exactly "on the fly", but I don't think there are many other ways that would scale up easily.
    Hope it helps.

    posted in patch~ read more
  • weightless

    This is a vanilla version of the external @Johnny-Mauser mentioned.
    vsplitfilename.pd
    vsplitfilename-help.pd

    posted in technical issues read more
  • weightless

    @prandam You can have many different variables in a message, which you call with $1, $2 etc. You can put them in whichever order you want to construct the message. This would be an example: Screenshot 2019-07-24 at 03.02.00.png

    Also this abstraction might be useful (I don't remember who made it) to split the filename from its path.
    vsplitfilename.pd
    vsplitfilename-help.pd

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!