I'll take a look at it. It would really help if you included some or at least one of the samples in your zip

Ahhh my patch wont work, you have to change the final message box- I messed up the order of the parameters.

Let's go over it:

240 - status
64 - manufurer id

• Channel number ($1 in argument, $2 in message)
  16 - sysex function
  0 - Group num (not sure what this is may be internal external storage)
  3 - Machine ID number
• parameter number ($2 in argument, $3 in message box)
• source number (1 - 4 audio sources) ($3 in argument, $4 in message box)
• parameter value ($1 in message box)
  247 - end

So, your message box should read [240 64 $2 16 0 3 $3 $4 $1 247(

sysex.pd <- fixed version

@hp3 "Can you provide some advice on how I would merge the fixed values, the slider value and the arguments into a single message?"

The methods have already been given to you, but I will do it for you anyway cause I'm such a nice guy. Then Ingox or David will probably show up with more elegant solutions.

sysex.pd

If I understand the question right, you are looking for an easy way to copypaste your slider and modify only the controller number?

You can use either list prepend or a message to crete a two bit list consisting of cc# and val before sending it off to the sysex message box which now uses two $ vars. I reckon you could use [pack] as well. I'm not sure which is more efficient, but a message box takes up less space...

Im pretty sure the [<~] is in the pd extended distribution as well... You are doing 1ms dips. I'd expect that to produce audible clicks under any circustances, unless you are lucky to hit a suffiecntly low-amplitude spot of the sample. Try increasing the duration and slope of your dips

The audio sends and throws work as a separate buffer, allowing you to do DSP feedback at blocksize latency, but they take up more CPU time and memory than a direct patch cord. I'd go with the latter and sacrifice neatness over performance when possible

It happens with vanilla and purr data too. I seem to remember some discussion of it on the mailing-list. Here's what I just found:

"For an individual patch, I can write desired values into the canvas definition line "#N canvas X Y ..." in the patch's pd file" (https://www.mail-archive.com/pd-list@iem.at/msg08703.html )

Meaning editing the .pd file in a text editor (you can write and save patches like that too if you have the guts)

BUT, I am not sure about subpatches...

Ah, ok, more manipulation is going on. Check my second suggestion:

But you could also have several custom messages for the volume control vline~ depending on what is being done with the sampleread vline~

Let me check your patch before I talk again...

---edit---

Ok, I see now that you are using phasor to drive the samplereading. My setup would then look like this:

You can change the values on the [<~] and [lop~] to suit your needs

I haven't checked the patch yet, but some thoughts. If you're already using vline~ then why not use a second one running in sync for the volume dip. Like say the ramp runs on a message that says [0, 1 100(, the second, for the volume control could go [0, 1 10 0, 0 10, 90( [that is 10 ms fadein and 10 ms fadeout] - both executed by the same bang.

Also, if you're using Purr Data, as I suspect from your other thread, you have access to some audio math that can do comparisons, like <~, >~, etc. Rather than the threshold, you could just use a [<~0.9] after vline~ and lopass filter its output for desired slopes. Like this:

[vline~]
| |
| [<~ 0.9] (will produce 1 when true, 0 when false)
| |
| [lop~ 100] (will produce an exponential slope lasting roughly 1000/100 msec)
| |
| [send to VCA]
|
[send to sample reader]

The [loadsave] abstraction takes an argument specifying it's inititial directory. Other than that I have troubles seeing where you could go wrong, But do try to zip everything, attach it here and let me, and others, have a go at it.