Hi Matthieu,

I see your post is a little bit old but I'm experiencing the exact same problem now with my setup.
I'm using a Windows 7 machine with a MOTU 828x sound card connected via USB to the PC and Pd 0.48.1 vanilla.

Here what I've done:

1. I've checked the "Use Stereo Pairs for Windows Audio" inside the "MOTU Audio Console";

2. opened PD and selected "standard MMIO" as driver from the "Media" menù;
3. now here's the list of outputs as it appears from the drop-down menu of "Media/Audio Setting.../Output device":

• MOTU Analog 3-4
• Loudspeakers (devide High ...
• MOTU Main-Out 1-2
• MOTU ADAT optical A 3-4
• Digital Output MOTU Audio
• MOTU ADAT optical A 1-2
• MOTU Analog 1-2
• MOTU ADAT optical A 7-8
• MOTU ADAT optical B 3-4
• MOTU Analog 7-8
• MOTU Analog 5-6
• Digital Output
• MOTU SPDIF 1-2
• MOTU ADAT optical B 1-2
• MOTU ADAT optical A 5-6
• MOTU Phones 1-2

As you see this list is pretty messed up and the names of logical consecutive output channels are not consequential. I would like to have 8 analog outputs from my MOTU so I selected the first item on the list (MOTU analog 3-4) then specified a total of 22 channels.

I'm obliged to set 22 as the total number of output channels because in my list MOTU Analog 5-6 are the last analog elements present. Because items in the list represent pairs of channels, this item corresponds to logical channel 21 and 22.

4. Then I created the dac object this way:

[dac~ 13 14 1 2 21 22 19 20]

Here's an image

This way I'm able to hear sound on all analog outputs of the MOTU even if I'm experiencing variuous 'clicks' and a series of "resyncing audio" messages inside the PD console...

I confess, this method is the only way I'm able to make this setup work but it seems to me to be pretty messy and not intuitive at all.

What seems to be even worse is that analog audio outputs inside the device list seems to change their order at each computer restart, so every time I have to restart from scratch.

• Is there some easier solution to this problem?
• Maybe a preference file I can create for PD to load at each startup containing all these settings?
• or there may be a way to programmatically select correct "analog outputs" from the device list in my patch (even if string parsing doesn't seem to be so easy in PD to me).
• Would launching PD from console, maybe from an ad-hoc script, solve the problem?

Thank you so much for your support
M

Time to start contributing some knowledge back to the wonderful world that is the internet; today, a step by step nice and easy tutorial on getting started to building your own MIDI controllers with the arduino.

When researching for my ableton controller project, I didn’t find much out there about using firmata on an arduino to send data to software. The standard approach just seemed to be create the code in the arduino language, upload it to your board and hack one of those MIDI to USB cables as a bodge job way of getting the MIDI out of the arduino.

So why firmata and pure data? Well the whole idea of firmata is that you flash it to your arduino, and it throws out serial about whats going on with the arduino inputs and outputs, then you decide how the software treats the readings coming in and going out.

Theory out the way, lets build some controllers. You’ll need a few things…

HARDWARE:

An arduino and something to wire into it (for this i’ll be using a pot)
A USB cable for your arduino
SOFTWARE:

Arduino – http://arduino.cc/en/Main/Software
Pure Data – http://puredata.info/downloads
Firmata – http://at.or.at/hans/pd/objects.html#pduino
Something to patch your new controller into; like Reason or Ableton Live

1. SETTING UP FIRMATA AND PURE DATA

Install Pure Data and create a folder to store all your patches somewhere. Unzip Firmata and add the files ‘arduino.pd’, ‘arduino-test.pd’ and ‘arduino-help.pd’ to your new Pure Data folder. The ‘arduino.pd’ file is the object that we use in PD for opening up communication with your arduino and routing it to PD. Done? Awesome, your software is almost set up.

2. FLASHING FIRMATA TO YOUR ARDUINO

Install the latest version of arduino and open it up. Connect your arduino with the USB cable to your laptop (i’m using a macbook for this by the way). In the example patches, open up “Standard Firmata”, select your board (im using an arduino mega), and your serial port (look for tty.usbserial for use with a USB cable). Then compile and hit the upload button and your arduino is now ready to use firmata and communicate with Pure Data!

3. WIRING UP A POT

Potentiometers are cool, and theres a great arduino tutorial of how to wire one up here: http://www.arduino.cc/en/Tutorial/Potentiometer

Basically, all you need to know is that there are three pins; your two outer pins govern voltage flow across the pot, meaning one has to be 5V and the other has to be ground. It doesn’t matter which, but your 5v pin is going to be where your pot reads maximum, so convention dictates this should be the right hand pin. The center pin needs to be connected to an analog in on the arduino and will read the value of the pot as it sweeps from ground (0v) to 5v.

All wired up? Plug it into your laptop and open Pure Data, we’re ready to get things talking.

4. SETTING UP OUR PATCH

Open the example “arduino-test.pd” Pure Data patch you copied over earlier. It should look like this one…

The test patch has everything we need to open a connection and enable pins. Firstly, lets delete a bunch of stuff and make our window a bit bigger. Hit Command + E to enter edit mode in Pure Data.

Ok a quick explaination; the key component here is the ‘arduino’ object. This is being drawn from the file you copied in earlier, and is what communicated with your arduino. Here we can do everything to control the arduino from opening a connection, to receiving data.
The large grid allows us to set the mode of each pin on the arduino. Remember pins 0 and 1 are reserved for Rx and Tx. I’m using analog pin 4 for this demo, so I’ve set my pin mode for pin 4 to ‘analog’.

Now we can plug our arduino in and get a reading from the potentiometer.

5. ARDUINO INTO PURE DATA

With your arduino plugged in, hit command and E to bring us out of edit mode. In our patch, click on ‘Devices’ above the arduino object and open up the pure data terminal. (That other thing that loads with PD that has all the scary code in)

The “Devices” message connected to the arduino object pings your computer to find what devices are connected and on what serial ports. Since we’re using a USB cable to connect our arduino, we’re looking for something with ‘usbserial’ in it, in this case; port 2.

Select the relevent port in the green box at the top (remember the first box is ‘0’, second is ‘1’ and so forth) and hit ‘Open’ to establish a connection. Check the terminal to see if the connection was sucessful.

Now lets check we’re getting something in. Create a number box (Command + 3) and connect it to the relevent pin on the ‘Route analog’ box at the bottom. In this case, pin 4.

One more thing; if you’re not getting any readings in, you’ll need to click on ‘pd old analog/digital controls’ and enable your pins here too. What I tend to do in my patches is just not include the large grid but make my own ‘old pd’ controls custom to what i’m enabling/disabling to save space.

Here’s what the ‘old analog/digital controls’ subpatch looks like (pin 4 enabled)…

Come out of edit mode and check that you’ve got readings. If so congratulations! If not, troubleshoot, start with making sure your usb connection is opened, make sure all the correct pins are enabled (remember you’re counting from 0 not 1 on most of these buttons in PD, it’s just the way computers work).

6. SCALING READINGS TO MIDI

So we’ve got a reading and chances are it’s to 3 decimal places between 0 to 1. No problem, create a new object (Command + 1) and type “autoscale 0 127”. This allows us to scale the input to a min and max value, in this case 0 to 127 of MIDI. Next, lets get things looking nice, create a new object and type “knob”. Connect this AFTER the autoscale object. (the knob is default set to read inputs from 0 to 127. Then create another number to display the scaled MIDI data coming out, and finally a new object and type “ctlout 1”.

It should look something like this…

The second box should be outputing values from 0 – 127 now, and the knob giving a visual representation of your potentiometer.

Now lets patch it into ableton…

7. PURE DATA TO ABLETON LIVE

Firstly, you’ll need to set up your macs IAC driver if you’ve not done this. Basically you’ll need to go into Audio/MIDI preferences and enable your IAC driver. Then create a new input and output. One for input to DAW and one for output from DAW. Google around for a tutorial on this, its really simple, a 30 second job.

After you’ve set up your IAC driver, go back to PD and go to preferences > MIDI Settings, and connect your IAC driver.

Open ableton and go to its MIDI preferences. Create a device listing for your IAC driver and enable its ins and outs into ableton like so…

And thats it! Create an instrument and try to assign something! I’ve got it controlling the brightness of a bass sound here.

Shout out for Facu who requested this tutorial. Hopefully it’ll help some of you looking to get into this stuff and start building things but with no idea where to start.

@Johnny-Mauser Are you still on OSX 10.8?

At some point in the future I'm going to have to drop both WinXP and OSX 10.8 support because current versions of the GUI toolkit don't support those systems anymore. It's not a priority right now, but I am seeing various speedups and new features in the newer GUI toolkit versions that will help improve Purr Data. I'll post a message about it to the list before it happens, but when those features hit a critical mass I'll need to make the switch.

@robertsyrett A few things Purr Data has which Pd Vanilla doesn't:

• infinite undo
• GUI presets (skins)
• introspection objects (which can be used to get abstraction args): canvasinfo, pdinfo, objectinfo, classinfo
• ships with externals like Pd-extended did
• internal preset objects which work out-of-the-box with abstractions (preset_hub and preset_node)
• Bezier curve cords
• guaranteed pixel-exact box sizing across all platforms
• ability to create scalars inside object boxes
• grouping/affine transforms/images/sprites/opacity/standard-color-formats/standard-mouse-callbacks for data structure drawing commands
• working event callbacks for data structure array elements
• canvas array fields for data structures with "pointerless" field mutation (experimental)
• hyperlinked object errors in Pd Window
• cross-referenced help patches with hyperlinks
• complete list of arguments expansion with "$@" in both object and message boxes
• tooltips for iemgui dialogs
• click-draggable iemgui sizing
• click-draggable iemgui labels position
• click-draggable GOP canvases/canvas redrect/grid/scope~ sizing
• "Tidy Up" function which works well
• one-to-many/many-to-one/many-to-many wire-connections
• out-of-the-box [initbang] functionality
• "Put" menu array trace colors
• "Put" menu array bargraph style
• click-draggable "Put" menu graph sizing
• a fairly standard properties dialog for scalars
• throttling iemgui and scalar GUI updates
• ability to change ds array element drawings without having to redraw the entire scalar which contains that element
• single preferences panel
• ability to draw scalars in a box outside of which the contents are clipped
• simple testing framework to make sure all externals instantiate without crash or memory errors
• various fixes to externals that don't use aliases correctly
• various fixes to the loader
• find in console with results highlighted
• duplicate console messages get prefixed with number incremented in brackets
• fullscreen mode
• standard open/save dialogs under Gnu/Linux
• object z-ordering (move to front/back)
• standard keybindings inside editable object/message boxes and performant copy/pasting that doesn't freeze Pd with large amount of text
• lots of abstractions which are part of Ico's "K12" mode. I haven't ported the K12 interface yet but the abstractions are functional and handy.
• dropdown menu atom box
• ability to paste Pd source file into running instance

That's heavily biased toward what I've been working on lately which is improvements to scalars. But that should give you a decent idea. Also-- Purr Data doesn't include Deken, and Gem doesn't currently ship with the OSX version.

Here is an updated version
arguscore-update.zip
and a few Purr Data compatibility replacement objects: purr-data-compatible-replacements.zip

A creation argument only object driven system for instant music making;
Objects so far;
Required;
globaltimer  - outputs a 10ms bang to drive all objects;
globalsync   - resets all objects to zero or start;
audio~  - dac~ catcher~ for all throws~, output level, mute;

Sound Objects

By default sound objects start playing at the bpm of the first argument

basspump - args - bpm note distortion duration
wood - args - bpm note duration
tremsaw  - args - bpm note vibrato distortion duration
tremsine - args - bpm note vibrato noise duration
noisy - args - bpm note vcfq duration
kauplus  - args - bpm note string-resonation duration

Effect Objects

sqr - args - 16 required(0 or 1) bpm (starts playing by default)
                          overides sound objects autoplay
                          2 optional args for cursor offset and pitch if font different
                          has 16 outlets to send 0 or 1
echo-delay-bpm  - args - bpm feedback(0 to 100) level(0 to 100)
echo-delay-ms  - args - millisecs feedback(0 to 100) level(0 to 100)
pan-level - args - pan (-100 to 100) level (0 to 100)
autopan  - args - width (0 to 100) frequency (* 0.01) level (0 to 100)
fade - args - millisecs to fade-in pecentage of level to drop to (0 to 100) millisecs to fade-out
filter - args - highpass (midi note to frequency) lowpass (midi note to frequency)
                          (0 to 135 equates to approx 8Hz to 19912Hz)
start-delay-secs - args - seconds (delays the autostart of the connected object)
start-delay-bpm  - args - bpm (delays the autostart of the connected object)
stop-delay-secs  - args - seconds (outputs a one at the end of the delay which can connect to a globalsync)
stop-delay-bpm   - args - bpm (delays the autostart of the connected object)

isolator - sits between two sqr's and sends a signal to start/stop the receiving sqr
seqnotes - four pairs of note & velocity that receive sqr ones to fire a connected sound object

Notes
Can crash Pd when making lots of edits to arguments, particularly while playing, so save often
There is a [declare -path objects] hiding behind the audio~ object
Fixed missing note and velo message for tremsaw
Two more arguscore patches can be open at the same time providing only one patch contains the globaltimer and audio~ objects (see arguscore-2.pd and arguscore-2-b.pd)
new objects
kauplus, autopan, fade, filter, stop-delay-secs, stop-delay-bpm;

I'm going to have to plead myself stumped once more I'm afraid. I really like the concept of MIDI routing without using Audio/MIDI setup, and MidiPatchbay is easy enough to use, but the patch is still not connecting as I had expected it to (somebody only barely understands the basics of computer science if claiming so isn't hubris on my part). My process is as follows:

1. Start MIDIPatchbay, create a single universal MIDI strip with both input and output - name "PD-Input"/"PD-Output" for reference. Allows all notes, allows all messages, clocks in real-time.

2. The patch itself doesn't show up in Audio/MIDI setup. That's fine, as I understand it the MIDI signal is traveling through MIDIPatchbay anyways. IAC is turned off and no software instruments are installed. I can close down Audio/MIDI setup and ignore it.

3. Start Mainstage, make sure that the volume is up, a patch is readied, and that Mainstage recognizes that there is a MIDI input available. Mainstage recognizes "1 MIDI input available"

4. Start PD-Extended and open the Sequencer patch.

5. Go through the process of making sure all components of the patch are functioning (it has a sequence tempo set, all the notes are active, volume is up, all the usual goodies).

6. Check DSP to on (I don't think it's necessary, but I tend to idiot proof my processes).

7. Set MIDI output from PD-Extended to "PD-Input" from MIDIPatchbay.

At this point I have all three pieces of software running, I believe in the correct order, and connected to one another with the only glitch being that I don't get a lick of audio. I'll dump the patch here for reference:

MIDI Sequencer Array.pd

I try to keep things fairly self-explanatory in terms of sends/receives and with comments within the object arrangement, but here's hoping it's legible. If the problem is in the coding of the patch I can take it across to that section of the forum. That said, even making a simple patch to create a note with set number, velocity, and duration on manual bang and send through the midiout doesn't seem to be arriving to Mainstage. I suppose I could use one of my other programs capable of MIDI synthesis, but that seems superfluous.

I really appreciate the help, I've worked with PD less frequently over the past five years or so than when I was first learning the ropes; it always seems like I have to re-learn a few things as well as double check on my knowledge of possible objects to use... Always something new.

I'm also curious about what triggers the Stack Overflow.

A safety mechanism that puts an upper limit on how deep an immediate "chain reaction" can be in response to an event like a mouse click, key press, netreceive, or clock callback (.e.,g. a bang coming from [delay 1000]). When I say "chain reaction", I mean an initial message to an object triggers an outgoing message to another object, and so on until there are no more outgoing messages to process. When I say "immediate", I mean the messages get sent without any logical time in between.

Here's an example:

[bng]
|
[bng]
|
[bng]

If you clicked the object chain above, you get an immediate chain reaction 3 objects deep.

Now, if you extended that chain so that there were 1001 [bng] objects-- each with a single connection to the next-- you'd get a stack overflow error because it exceeds the limit Pd puts on how deeply a single message is allowed to flow in an immediate chain reaction.

The way Pd is coded, these simple examples actually end up using recursive function calls in C. Using recursion with too many levels can end up overflowing the stack and cause a crash, which is why you get that particular error message. (1000 may be too small a number nowadays, but recursion is complex and I'm not sure how one would come up with a better number.)

When you use recursion explicitly in a Pd diagram-- that is, hooking an object's outlet to an inlet that is back up the chain-- you make it way more likely to hit this particular error. You can imagine that your recursive diagram ends up "unrolling". That is, if you have a chain of 4 objects where the bottom one connects back into the top one and recursing 251 times, you're going to hit a stack limit and get the error.

The [until] object solves this "explicit" recursion problem-- it sends a bang to its outlet, and when the resulting immediate chain reaction has finished it sends another until the specified limit is reached.

So if you have this:

[10000(
|
[until]
|
[bng]
|
[bng]
|
[bng]

You go two objects deep for the bang coming out of [until], then three more for the first time through the chain of [bng] objects. So now we're 5 deep. But once the first iteration of the [bng] objects are done they unroll, so we're back to being just 2 levels deep. Then the [until] object starts its next iteration, which goes 3 more deep, then unrolls. It can do this indefinitely, which is why [until] is preferred over using recursive object chains in Pd.

Edit: There is a general [markov] abstraction now at https://forum.pdpatchrepo.info/topic/12147/midi-into-seq-and-markov-chains/45

This is one of the early projects by @Jona and me. Happy to finally release it.

markovGenerator

Generates music from learned material using Markov chains. It is polyphonic, plays endlessly and supports Markov chains with variable length.

markovGenerator.zip (updated)

Usage:

1. Record midi notes or load midi files
2. Make Markov system
3. Play

1. Record midi notes or load midi files
   Until you reset the memory, each new recording will be added to the memory. The recorded material is seen as a loop, so that the last note is followed by the the first note, for endless play. markovGenerator handles recording midi and loading midi files differently: When you record midi, it will record notes according to the midi clock every sixth midi tick. This is defined in the counter in [pd midiclock]. So that way, breaks are being recorded and the rhythm is preserved. When loading midi files, no breaks are being recorded, the notes are just recorded in order, so the rhythm will be lost. In any case, simultaneous notes will be recorded as chords, so polyphony is preserved.

2. Make Markov system
   Set markovOrder to specify the length of the Markov chain. The higher the order, the more musical information will be kept, the lower the order, the more random it gets. You can use soundFilter and channelFilter to only use notes of the specified sound or channel. This is especially useful when working with midi files. Note that if there are no notes of the specified sound or channel, the Markov system will be empty and nothing will be played. Set the filters to zero to disable them. If you change the settings for the Markov system, click makeMarkov again for them to take effect. You can make new Markov systems with different settings out of the same recorded material over and over again, even when playing. If you record additional notes, click makeMarkov again to incorporate them into the Markov system.

3. Play
   While playing, you can change the note length, sound and midi out channel. Set soundOut and channelOut to zero to use the sound and channel information of the original material. Playing starts with the Markov chain of the last recorded notes, so the first note might be played first.

Use the markovAll section on the right to control all Markov channels at once. Here you can also set tempo, swing and midiSync, and you can save the project or load previous projects.

Have fun!

If it does not play, make sure that

• you recorded some notes,
• you hit the makeMarkov button,
• soundFilter and channelFilter are not set to values where there are no notes. Try setting the filters to zero and hit makeMarkov again.

About the Markov system:
You can see the Markov system of each Markov channel in [text define $0markov]. Notes are stored as symbols, where the values are joined by "?". A note might look like 42?69?35?10 (pitch?velocity?sound?channel). Chords are joined by "=". A chord of two notes might look like 40?113?35?10=42?49?35?10. Notes and chords are joined to Markov chains by "-". The velocity values are not included in the chains. Sound and midi channel values are only included, if soundFilter or channelFilter are off, respectively. Markov chains of order three may look like 42?35?10-36?35?10=42?35?10-60?35?2 with filters off and simply like 42-37-40 with both filters active, only using the pitch value.

Requires Pd 0.47.1 with the libraries cyclone, zexy and list-abs.

Purr Data is finally released!
Purr Data inherits the goodness of Pd-l2ork and runs on Gnu/Linux, Windows, and OSX. Infinite undo, enhanced editing and 2d drawing, and most of the the externals from Pd-extended (plus more from Pd-l2ork).

[Edit]
2.2.4:

• fix [wrap~] inconsistency
• port mouse events from [hcs/cursor]
• fix bug with dollarsigns in struct names
• add some "legacy_mouse" classes to support externals that report mouse events: "legacy_mousemotion", "legacy_mouseclick" and "legacy_mousewheel"
• fix bug loading default libs on OSX

2.2.3:

• fixed overallocation bug that made loading soundfiles into arrays take up unnecessary amount of memory (4x-8x overallocation)
• fix some utf8 string handling routines
• port fixes for [soundfiler] from Pd Vanilla
• fix bug with "$@" that could cause invalid reads in some cases
• fix [initbang] functionality
• fix crasher in [pdinfo]

New in 2.2.2:

• fixed usability issues with the dropdown object

New in 2.2.1:

• fix stray GUI bugs
• fix some external libs that weren't building under Windows
• fix some OSX key event bugs

New in 2.2.0:

• fix GOP sizing algo to accommodate small GOP abstractions
• turn off anoying Gnome-keyring popup that appears on some systems
• bump nw.js GUI toolkit to 0.22.1
• fix arrow-key navigation-- use arrow keys for scrollbar navigation in runmode, turn off in editmode
• ignore iemgui label in bbox computation for "-legacy" mode
• fix OSCx library on arm builds
• guard against more out-of-order messages from Pd to GUI
• clean up and simplify build instructions
• leave enough space in GOP abstractions to accommodate all xlets
• fix search path bug
• update some of the documentation, removing old "messageoddness" patches that no longer apply to Purr Data
• update unauthorized library
• clean up and simplify the repository code/structure

New in 2.1.2:

• minor bugfix in the console (duplicate messages weren't printed after clearing)
• some minor fixes in the default startup configuration
• some cosmetic changes in the accompanying README and license information
• various bugfixes in objects and internal API functions (message boxes, dropdown atom, loadbang-related issues)
• updated lyonpotpourri to the latest 3.0 version to fix various 64 bit issues on Linux and macOS
• saving the preferences is much faster on the Mac now
• new animated "About Pd-L2ork" popup; also, the proper version is now shown in the generic "About" box on the Mac

New in 2.1.1:

• normalized range for [bendin] (keep old behavior under legacy flag)
• added "mouseenter" and "mouseleave" events for data structures
• fixed "Recent Files" under Windows
• cleaned up documentation in repo
• fix for [midiclkin] (#255)
• added "l2ork_version" message for [pdinfo]
• make loader search order the same as Pd Vanilla
• fixed cord inspector font size
• silence spurious error when autopatching a signal object
• added a [dropdown] object for choosing a value for an atom box (interface not stable yet)
• made gatom resizable by click-dragging in edit mode
• added "<ctrl-mousewheel>" for zooming
• added solarized and inverted solarized gui presets
• fixed mycanvas stroke color updates
• improvements to mode 4 of intelligent patching
• fixed "<Delete>" not deleting a selected object on some systems

New since rc5:

• fixed display bug with [vu] on graph-on-parent canvas
• fix documentation for timer-help.pd
• fix "open" method for [ggee/image]
• default to the user's home directory on OSX app bundle
• open the help browser file browser in the doc folder
• add a canvas "Print" menu item (under "File" menu)
• allow option to save the zoom level with the canvas
• fix a data structure crasher

please report lots of bugs to

https://git.purrdata.net/jwilkes/purr-data/issues

Binaries:

https://github.com/jonwwilkes/purr-data/releases

Purr Data release candidate 5!

• small fixes to OSX app bundle name and build instructions
• fixed OSX app bundle name
• fixed GUI errors with some GUI objects on GOP
• use cat icon for patches
• fixed a [grid] crasher with binding symbol leak
• fixed [grid] line drawing bug and GOP xlet display
• added dialog and scale handle for [grid]
• ported moonlib/knob
• get rid of some extraneous debugging messages
• allow to install Purr Data alongside Pd-l2ork
• Scope~ code cleanup
• fixes for arm build
• added some OSX app bundle dependencies for [fluid~] and others
• fix saving preferences under OSX
• added startup paths and libs to preferences dialog
• use "Purr Data" in OSX menu app
• help browser fixes
• fixed MIDI preference saving on OSX and Windows
• added a "Recent Files" menu to the "File" menu
• get consistent behavior for present working directory when opening/saving files
• fix Volume name for OSX dmg installer
• try to standardize a deterministic package name when compiling Purr Data
• add a Pd-l2ork-specific version number
• add command line open args to "Recent Files" list
• fixed crasher with ds "canvas" field
• allow saving the zoom level per canvas

please report lots of bugs to

https://git.purrdata.net/jwilkes/purr-data/issues

Binaries:

rpi Raspbian (armv7l)

Debian Jessie 32-bit

Debian Jessie 64-bit

Ubuntu 14.04 32-bit

Ubuntu 14.04 64-bit

Ubuntu 16.04 64-bit

Windows with 64-bit GUI

Windows with 32-bit GUI

OSX 64-bit

OSX 64-bit (10.8)

Whoops! Missed this post, just found it by accident. Don't know if the OP gave up but might as well respond for the archive and mention that I finally filed a bug on this issue.

The known problem here -- as I have stated in other threads -- is probably not a midi clock issue but Active Sense messages (the Yamaha PSR-E323 midi implementation chart indicates that these are implemented in that device). Active Sense is part of the System Realtime group of commands in the midi spec (also includes clock, stop, start, and continue).

If configured correctly, Midi Patchbay on the MAC will stop these messages, but it can only be configured to block the entire System Realtime group. If the other messages are needed, a more selective option might be Midi Pipe, thou I have not yet tested this. It can be downloaded from here:

https://www.macupdate.com/app/mac/10541/description

See also these threads:

http://forum.pdpatchrepo.info/topic/9565/midi-issue

http://forum.pdpatchrepo.info/topic/9501/filter-out-midi-clock-information

http://forum.pdpatchrepo.info/topic/9635/does-midirealtimein-still-work