• whale-av

    @jameslo Not my subject..... and no idea if it is useful..... but I throw it into your thread anyway as it details a method (I think) for what you are aiming for..... and I know that you know how to logically construct a patch from a method.
    David.
    Capture.JPG

    posted in technical issues read more
  • whale-av

    @ddw_music Is that OSX or Linux?
    Widows 7 reports correctly even with the delay.
    David.

    posted in technical issues read more
  • whale-av

    @oid [pack] [unpack] is a great idea....
    David.

    posted in technical issues read more
  • whale-av

    @WEIRD1 As you want floats and bangs (and maybe symbols and lists one day?) to pass through unchanged...... maybe build your "router" with a bunch of [spigot] objects ..... 3 per inlet and each connected to one of the 3 outlets.
    Then a counter that rotates 1, 2, 3 as it is banged (by your bang [inlet] ) and its output sent to the control inlets of the spigots via [== 1] [== 2] [== 3] for the first inlet and [== 3] [== 1] [== 2] for the second..... etc..... I think.......
    When the counter output is 2....... for example.... [== 2] will output 1 and open the spigot...... whereas [== 1] and [== 3] will output 0 and close their spigots.
    You will have built a rotating multi-gate in vanilla........
    All vanilla.....Started for you but untested..... so please check it...... bof.zip
    (( Just noticed that you should also change the initial [spigot] arguments for each inlet so that they route correctly on creation.))

    When you have finished it save it and use it in your patches as an abstraction (you will have created your first)..... by "putting" [bof] in a patch. You should probably save it with a name that makes more sense though.
    You could even make a [bof-help] file so that it will be understood later.

    BUT!!! change the send/receive names first..... to [s $0-control] and [s $0-out1]....etc.... or when you use the abstraction more than once the instances will be receiving each others messages....... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4

    A lot to absorb.... but worth it....!
    David.
    Capture.JPG

    posted in technical issues read more
  • whale-av

    @ah_dziz There is no "current index" but you can get the value at an index.
    Pd extended help was a bit more informative (and was correct)...... read.zip
    David.

    posted in technical issues read more
  • whale-av

    @ah_dziz The only thing that I can think of that would stop tables being drawn is if DSP is turned off, or the audio thread is not running because Pd has failed to communicate properly with the OS.
    But you say audio is running fine.
    Maybe upload a patch you have made that is not drawing to the table/array and we can see if it works for us...... use the "Up arrow" Capture.JPG symbol above the post that you are writing.
    David.

    posted in technical issues read more
  • whale-av

    @Bébéchat MOTU use the proprietary HUI midi protocol..... https://en.wikipedia.org/wiki/Human_User_Interface_Protocol
    The Mackie control can be used in HUI mode to control their devices, and lots of DAWs have HUI capabilities.
    Not sure how you hook into the midi ports but maybe they just appear in MidiOx or similar.
    But it will be midi messages that you will need to send/receive in Pd.
    This info on the format is miraculously still available........... https://forum.cockos.com/showthread.php?t=101328 ...!!!!!!
    [f] in Pd can now convert hex to decimal..... that will be a huge help.
    But unless you can find a datasheet for what you want you are going to have to sniff the data and reverse engineer the HUI.
    You might have more luck adapting a DAW as a man in the middle.
    David.

    posted in technical issues read more
  • whale-av

    @cfry I had completely forgotten about this one......... http://www.pdpatchrepo.info/patches/patch/10
    It will need some work probably to update it for Pd vanilla.
    David.

    posted in technical issues read more
  • whale-av

    @WEIRD1 If you want a slope..... a ramp..... there needs to be a time element.
    So assuming you want a ramp upwards you need a message giving the value to ramp to and the time to do so..... and the time will need to be based on your [metro] value.
    Also, the jump back down needs to happen after that time interval.
    Please use trigger [t] where you want to make things happen in the correct order...... it makes the patch much easier to read..!

    There is an object [phasor~] that does exactly the same though... !
    The [vline~] method broken down (so very messy, but can of course be simplified, and even returned to your method)...... and the [phasor~ equivalent.......
    simple.pd

    You don't need the [$1 $2( after your [pack f f] but you will need a separate [pack f f f] for the jump back to zero (just like in the "print" part of the patch).
    "$2 out of range" means that there was no $2 value arriving so no value could be given.
    If you are using [pack] it can also be that $1 was the wrong atom type..... so $2 filled $1 and then $2 was missing.
    I am not seeing that in this patch though.

    I don't know what you want this for, but you might want to smooth the return to zero by giving a little time (3-5ms...?) for that to happen.
    David.

    posted in technical issues read more
  • whale-av

    @WEIRD1 The patches were built back in 2013...... but no attachments....
    https://dorkbotpdx.org/blog/jmej/serge_subotnick_and_pure_data_programming_sound_for_dance/
    You might find most of what you need in the synths on this page......
    http://www.pdpatchrepo.info/patches
    David.

    posted in abstract~ read more

Internal error.

Oops! Looks like something went wrong!