-
bocanegra
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
-
bocanegra
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
- Channel number ($1 in argument, $2 in message)
-
bocanegra
@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.
-
bocanegra
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...
-
bocanegra
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
-
bocanegra
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
-
bocanegra
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...
-
bocanegra
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
-
bocanegra
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] -
bocanegra
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.