• 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

    posted in technical issues read more
  • 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

    posted in technical issues read more
  • 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.

    Screenshot_2018-11-01_17-50-06.png

    sysex.pd

    posted in technical issues read more
  • bocanegra

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

    Screenshot_2018-11-01_07-28-53.png

    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...

    posted in technical issues read more
  • 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

    posted in technical issues read more
  • 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

    posted in technical issues read more
  • 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...

    posted in technical issues read more
  • bocanegra

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

    Screenshot_2018-10-31_14-02-29.png

    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:

    Screenshot_2018-10-31_14-10-12.png

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

    posted in technical issues read more
  • 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]

    posted in technical issues read more
  • 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.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!