• Booberg

    Don't know what to call this really. I put this together to prevent unwanted control changes after loading presets. A useful utility for hardware-controlled patches with presets.

    -Inlet 1 passes control signal to the outlet.
    -A bang to inlet 2 activates the temporary threshold/gate.

    After activated, no control changes will pass through until a change that exceeds the threshold value is registered. (Relative to the control value at activation).

    -(optional) Set threshold through inlet 3. Default is 10.

    Example:
    *Control signal through inlet 1 is at 50 when gate gets activated with a bang to inlet 2 (threshold set at default value, 10).
    *Values of 41-59 will not pass through.
    *A control signal <=10 or >=30 opens the gate.
    *After the gate is opened, the control signal passes through until another bang is sent to inlet 2.
    TemporaryThreshold.pd
    Skärmavbild 2021-02-17 kl. 17.32.10.png

    If there is already an abstraction or external out there that does this in a better way please let me know :)

    Noticed a possible source or errors, if the 'float-box' were to send its value to the hot inlet of the 'subtraction-box' before it does the cold inlet. Not a problem on my system but this might be safer with a trigger to make sure..
    Cheers!

    posted in abstract~ read more
  • Booberg

    Here we have it! I didn't test it all to much but I think it's fairly robust. Maybe it could be done in a simpler way? I added that "middle" spigot to hopefully keep it from doing redundant computations when not active.

    Skärmavbild 2021-02-17 kl. 16.30.36.png TemporaryThreshold.pd

    posted in technical issues read more
  • Booberg

    @whale-av

    That's food for thought! It isn't enough for the application as is (since it's impossible to know how far or close any of the controls might be to one of the "threshold values" so to say). But here's the plan. If i save the current control value at the point of loading i could then take the value of the difference between the "real" controller value and the saved one and apply that suggested threshold method, connected to a spigot.. I'll be right back with a patch.

    Thanks for helping out again!

    posted in technical issues read more
  • Booberg

    Before i possibly reinvent the wheel with this i thought i should ask if there is a solution for this out there already.

    The basic idea is this: When i have loaded a preset on my instrument i don't want my patch to react on 'small' control changes (essential if using a DIY controller with some jittering signals). So i'm thinking i should have some threshold value, within which control changes won't register.
    My spontaneous idea is that, whenever the "load preset" button is pushed, to have spigots shut on each control parameter. And then have the 'current' controller values set some 'clip thresholds' that, when exceeded, open said spigots.

    Ideas?

    posted in technical issues read more
  • Booberg

    Couldn't find this info before so I'll post it here:
    [pd~ start -nogui blabla.pd(

    Will launch a headless subprocess. (osx 10.13)

    posted in technical issues read more
  • Booberg

    @whale-av Oh hell yes :) Thanks again

    posted in technical issues read more
  • Booberg

    @whale-av Will go on a quest for -nogui but it's for the near future i think. And I have to have GUI on the main process, so we'll se how that goes.
    The reverse i use (ELSE) is actually vanilla (i think?). And it reverses the order of a list! But now when i look into it deeper i se it's waay overcomplicated for just reversing a list of 2 elements.
    I did this now instead, same basic idea you posted :)
    Skärmavbild 2021-02-12 kl. 10.16.39.png

    Thanks so much for the feedback and help!

    posted in technical issues read more
  • Booberg

    Well yes, this is what i figgured. I was only really planning on sending the actual synthesized audio through that method but even so, it seems a shaky foundation. I'll stick to the straight forwards way of using the inlets and outlets of the pd~ objects and will have to have the audio snake its way through the sub processes. It feels a bit like a wild goose chase right now, because the laptop im designing this on only has 2 cores and this layput is so much worse for preformance on this machine :) but, as the Rpi has 4 cores i believe it could be worth it in the end. A valuble experiment if nothing else!

    Im using [prepend 'control value']-[send 'subprocess'] to get the values to where they want to go for now and it's proving to be a pretty neat way of routing things as i can then tap those 'lists' from [return subprocess] into a single send object that will send it to whatever parameter name is attached to each value. So i dont have to have a separate send object for each control parameter aswell. Just a nice, slight, convenience ;) I did have to use [reverse] to get the correct bang order for that.

    Ill just squeeze in a question here too.
    Can you open a subprocess with -nogui? Its not an accepted flag for the pd~ object from what i can se. What I forgot to try today was to type it in in the startup message i send to the object, maybe that could work?

    posted in technical issues read more
  • Booberg

    @whale-av that doesnt sound so scary, will definitively try it for signals that need to traverse both sub-processes. When i say audio rate i mean audio signal. I basically use audio for most data to get smooth value changes using the good old "[pack f ms]-[line~]". And since i have quite a number of modulation sources and destinations it is pretty much obligatory to convert most parameters to audio eventually anyways.

    posted in technical issues read more
  • Booberg

    It seems i've been worse off for researching this subject before experimenting with implementation. Very typical hehe. A lot of the threads i found were very old and i find the pd~ object is actually very user friendly at first glance.

    Future experiments will be running about 30 controller values at audio rate through the sub-processes to see how it preforms. If that format proves a challenge the hassle will be routing all the control level signals as they must all share one inlet if i'm not mistaken? I assume there are fast and easy ways of doing this but i'm thinking ill pack each signal with a symbol and use the route object inside the subprocess. however I do have a feeling this will be messy and wasteful. Maybe using arrays or a dynamic list somehow? Just ventilating my thoughts at this point :)

    Still looking for intel about sending audio between 2 sub-processes without having it passing though the main or having one within the other..

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!