• 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
  • bocanegra

    Supposing what you want is a bang at the beginning of each phasor~ cycle, I was going to suggest a [vline~] driven by a [metro]. But it will be less precise to useless at higher frequencies, so it depends what you will be using it for. Trying to send bangs at high frequencies itself can probably hang your system too.

    posted in technical issues read more
  • bocanegra

    You've posted several threads about the same issue. Whae_Av / David pointed you to pddroidparty's homepage for documentation on their custom abstractions. There's a provided [loadsave] object that ought to work (quoted from https://droidparty.net):

    [loadsave] - Wraps and openpanel/savepanel type of interface into a single abstraction that lets the user specify or choose filenames using the Android interface.

    posted in technical issues read more
  • bocanegra

    Natural Logarithm it is. Either he used an abstraction of his own, or an object of his own, or an extended object. It exists in Purr Data (I just checked), so the easiest solution might be to install that one besides your pd vanilla installation (I'm running both on linux)

    posted in technical issues read more
  • bocanegra

    There's no such object pd vanilla. Don't know about extended or purr data. If you're trying to do natural logarithm you can do that with [expr~].Or [line~] might be the one you are looking for?

    posted in technical issues read more
  • bocanegra

    @silverdrive the [ctlin] objects recieves all cc messgaes from all channels and outputs three floats: value, cc# and channel. There's a multitude of ways to reroute, rescale etc the cc values inside your pd patch. I'd use [pack] and [route] (see screenshot) but I'm sure there are other ways.

    Screenshot_2018-10-21_12-13-06.png

    posted in technical issues read more
  • bocanegra

    @seb-harmonik.ar Might be a late night mistake on my behalf. Can't replicate it today so I guess I'm wrong. Still baffled by the whole issue tho... I reckon the [f] in @ingox version works similar to the suggested pipe and delay. That was not what I thought I was doing with golf1, but anyway, no reason to beat a dead horse...

    posted in patch~ read more
  • bocanegra

    @nuromantix there's an abstraction missing in the zip file (the ar~ a simple envelope with exponential curves), I attached it in the following post, but here's the full zip with [ar~] included:

    addperc.zip

    posted in patch~ read more
  • bocanegra

    @ingox Tested it. It doesnt work. I get series of same numbers going just a few bangs in. Unless you connect the right sel out to the right f in and use the initial bang for the left f in. The sel argument is moot. It only matters for the first instance, in which you dont need a comparison anyway. Im not sure whether the [t b b] i used for the initial bang is necesary, I think not, but all in all, unless you delay the float that is "previous value" with one tick (initial bang) you get trouble.

    posted in patch~ read more
  • bocanegra

    Like this:

    [bang]
    | [r filelen]
    | |
    [f ]

    Or inother words, you can use the [f] object as a value holder that will output it's right inlet when banged on the left inlet.

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!