I am getting a different result in my code when I run a patch as a an abstraction vs on its own. The issue seems to be with a list append object and the right cold inlet. The patch does the following:
- takes a number input
- pass the number input to the hot side of the list append
- if the number input is <= 127, pass 1 to the right cold side of list append else if it is 128 or greater pass 1 + 1 (2) to the right cold side list append.
- format the list in a message, print the message
- and also print the value of the data directly.
Here is the abstraction patch:
Here is the main patch:
When I run the main patch and enter 127 then 128 into the number atom I get the following output in the console:
first problem is the number out of range. Second problem is that the $2 value in the message is not the same as the value printed from "print result".
When I run the patch on its own and use the number atom in the patch for the value I get a different output in the console:
In this case the value of "print result" and the $2 value in the message are the same.
It seems there is a difference in the order of execution of the print statements and maybe there is also a difference in order of when the cold inlet on the list append gets updated.
Why is there a difference when run as an abstraction and how do I correct the number out of range error?
thanks for your help.
I have an abstraction that builds a system exclusive parameter change message. I pass 3 arguments to the abstraction and it builds a system exclusive message from the 3 arguments and a value sent to the abstraction inlet from a slider.
One of the arguments corresponds to the source (audio channel) in a k1 hardware synthesizer. The decimal value of the source that goes into the sysex message is 0,2,4, or 6. But for ease of use I want to pass 1,2,3,4 as the value of the source argument to the abstraction, then have math convert that 1-4 value into the even numbers 0 - 6.
Here is a screen shot of the abstraction (k1sx) in the main patch with 3 arguments, 0, 41, 1 (channel number, parameter number, source number).
The abstraction should generate a midi message with the source number converted from 1 to 0 (1 - 1 * 2).
Here is a screen shot of my attempt to do this with an argument within the abstraction, which did not work...
Is there a way that I can take the $3 argument, subtract 1 multiply by 2 and then place this new value as the 2nd to the last value in the message box near the bottom of the patch?
ok, here is the main patch
and here is the abstraction that generates the sysex
All of this works fine if I operate one control at a time, but if I click the bang, the ui elements update and the midi messages print out correctly but the only parameter that changes on the hardware synth is the one corresponding to the rightmost control.
thanks for all the suggestions. I was able to implement the send and receive technique, that seems to work well in my situation.
However, I am noticing that when I use the bang to reset the values of the user interface, even though pd is sending out the correct midi messages for each ui element, the hardware synthesizer is not responding to the midi messages except for the last message received which would correspond to the radio button (right most control).
Is this due to midi sysex messages being sent too quickly for the synthesizer to process and it only process the last message? Is there a way to put a delay time in between the messages?
By "re-run" I meant unchecking edit mode from the Edit window.
By "re-opening" I meant close the patch from the File menu, then use the File menu to open the patch.
When I "re-open" the patch the abstraction sets the default values for the ui elements as I intend. But I have to close and re-open the patch file to acheive this automatic reset. I would like to achieve this when I uncheck Edit mode.
Alternatively, I am using your suggestion of a bang to the abstraction and also a loadbang in the abstraction to output the default values to multiple sliders.
My eventual goal is to have about 10 sliders and other ui elements to transmit midi parameters to a hardware synth. I want to have default values for all of the ui elements and an easy way to reset the ui to its default values after I have used the interface.
My current approach uses an abstraction to send a default/starting value to an outlet for each ui element. The sending of this value is triggered by either loadbang in the abstraction or a bang button in the main patch.
Is this the preferred approach? There may be 10 outlets in the abstraction.
It looks like my abstraction is working correctly. I needed to close the patch and reopen. When I reopen the main patch, the slider is at the default 50 position or whatever I set in the abstraction.
Is there a way to get the user interface to reset from re-running the patch instead of re-opening the patch?
I would like to have a slider with a starting value/position at the 50% position, so for example if the slider range is 1 - 100, then the starting value and position would be 50. I have used a bang to a message to the slider to set the starting value.
This works fine but requires manual input on my part to set the value of the slider by clicking the bang button. I would prefer have this happen automatically, essentially reset the patch user interface controls to defaults when I run the patch. I tried an abstraction and use loadbang to trigger this routine
end of abstraction
slider - main patch
But this did not output anything when the main patch runs.
how would I get something to run automatically in the main patch when the patch executes?