Calling functions in midi processors...



  • @Lindon

    const var Knob1 = Content.addKnob("Knob1", 0, 0);

    --- but of course when I go to my interface its nowhere to be seen....how do I make it show up in my interface? how do I even edit it.

    Controls should only be added this way to MIDI processors that aren't the user interface script. Is that the interface you are talking about? If so did you click the interface button (the one to the left of the callback buttons)?



  • @Lindon

    heres the snippet now.... it all seems broken to me

    There are no controls on the main interface. Did you add any in the interface designer? Or did I lead you to believe they were added by the other script?



  • @d-healey yes thats what you led me to belive I think...

    OK what is the process of adding a slider to the midi processor of a sampler and have it show up in the main interface?



  • @Lindon You have to add them to each separately.

    For example I have an instrument and it has a sampler with a MIDI processor for handling legato, and another MIDI processor for handling round robin (nice and modular).

    On my user interface I want to give the user a control to bypass the round robin script and to adjust the xfade time of the legato. But I don't want them to have access to the other controls of those scripts such as setting the playable range or the legato volume etc. So on my user interface I add a button and I connect this via parameter ID in the interface designer to the bypass button of my RR script, I also add a knob which is connected to the xfade knob of my legato script.

    It seems like more work duplicating controls and I was put off at first, but actually it's very fast to do and allows me to easily create scripted modules that can be used in different projects and with entirely different interfaces.

    I have a load of modules here you can play with - https://github.com/davidhealey/HISE-Scripting-Framework/tree/master/modules - I use the Connect to external script option from the context menu that appears when right-clicking on a MIDI processor's header.



  • @d-healey OK, thanks.



  • So then just the one outstanding question:

    why oh why cant I say this in my main interface script:

    const var myScriptProcessor = Synth.getMidiProcessor("myScriptProcessor");
    
    myScriptProcessor.myFunction(param,param);
    

    instead of this I have to create a set of interface widgets in myScriptProcessor, one for each param of myFunction then call another widget to execute the logic in myFunction

    What is wrong with exposing the method(sorry Function) and allowing me to call it from somewhere else?

    Surely we can all agree the current approach (if it is all we have) is a bit broken?



  • @Lindon said in Calling functions in midi processors...:

    So then just the one outstanding question:

    why oh why cant I say this in my main interface script:

    Because scripts can't talk to each other directly. You can do that using Global variables but it really isn't necessary.

    instead of this I have to create a set of interface widgets in myScriptProcessor, one for each param of myFunction then call another widget to execute the logic in myFunction

    Create your module and get it to work exactly how you want (makes it really easy to test the code is working) then add the controls to your UI that you want the user to have access to and link them together in the interface designer. It's a 10 minute job...

    What is wrong with exposing the method(sorry Function) and allowing me to call it from somewhere else?

    I can see this being useful and can't see a downside to it (maybe Christoph will see a pitfall) but it will kind of collapse the tree paradigm.

    Surely we can all agree the current approach (if it is all we have) is a bit broken?

    I haven't encountered any problems with it so far. Just requires a different way of thinking about problems.



  • It‘s definitely not broken, it enforces encapsulation and moves the responsibilty to operate on data to where it belongs.

    If you want to avoid multiple controls, store them in a global data object (or multiple variables) and use a single button in your target script that fetches all values and do the appropriate thing.



  • @Christoph-Hart there is nothing about callable functions that breaks encapsulation, so thats not a fair assessment I think. The responsibility to operate on data remains in exactly the same place, in the object where the function resides. All in the end we are talking about is a parameter passing paradigm, function call vs filling in (otherwise unused) widget values.

    in fact this

    myScriptProcessor.setAttribute(0,12);
    

    breaks encapsulation - so I can set an attribute in a midiProcessor but I cant call a function.

    You may have to excuse me I'm a SmallTalk programmer by training - so I have a bit of a purist view...



  • Yes there is - if you recompile the target script without recompiling the caller script, the function will point to a invalid root object and it will crash badly as soon as you call any API method. The lifetime of a compiled function must never exceed the lifetime of its root and this would make it very easy to violate that rule.

    Worst case in the current approach is calling setAttribute with an invalid ID.


Log in to reply
 

3
Online

491
Users

1.7k
Topics

12.8k
Posts