I was just trying to use [midiout] to send clock messages (to test a MIDI sync clock in other software).

I've already verified that Pd's ALSA MIDI project is connected to SuperCollider's input port. I can send note messages out of Pd and SuperCollider receives them. So there is no communication problem. (Linux btw.)

The only documentation says that [midiout] sends raw MIDI. So I looked up the clock messages in the MIDI spec:

11111000 = 248 = tick
11111010 = 250 = start
11111100 = 252 = stop

I'm sending these numbers to the left inlet of [midiout] and exactly nothing is happening in SC.

• MIDI communication Pd --> SC is working.
• I already set up the MIDIIn.sysrt function in SC.

So I have to conclude that my input to [midiout] is wrong.

However, I can't possibly figure out what the input should look like based only on the phrase "raw MIDI."

Can anyone clarify?

midiclock.pd

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

I am not sure if I understand the description of your problem, though I am not sure if it matters as long as it has anything to do with SYSEX failure in Pd.

Are you running both those interfaces directly in Linux?

Also, what version of Pd?

I do have some general info about obtaining and or maximizing MIDI/SYSEX performance with Pd.

Linux and Mac platform Pd is partially functional with regards to SYSEX but to obtain full functionality requires some minor tweaks be made to the source code and compiling Pd from said source. Windows Pd has it's own problems with SYSEX and MIDI, for which I know of no current solution.

edit: misread the post, I think...

To answer the original question posed (in case anybody searching this thread is actually looking for the answer):

MMC messages are sent the same way in PD as any other sysex message. The simplest method is a comma-seperated list message of the sysex bytes connected to a midiout object. This page lists the the specific syntax for MMC:

https://en.wikipedia.org/wiki/MIDI_Machine_Control

HOWEVER -- Sysex functionality may still be broken in Windows. (thou that was supposed to be fixed soon).

Good to see someone posting a synth editor on here as I've been building a few myself for some time now. Unfortunately I don't have any Casios so my ability to help with development is limited (a friend had a 101, too bad somebody nicked it).

I did find this list of sysex parameters specific to the CZ-1 so maybe you can use it to add in those missing features.

http://www.synthzone.com/midi/casio/cz101/sysex.html

Edit: URL says CZ-101 but the text says CZ-1, so you'll have to be the judge.

Edit2: Maybe this link will help more:

http://www.kasploosh.com/projects/CZ/11800-spelunking/

http://www.abdn.ac.uk/~mth192/dx7/sysex-format.txt

hi here is a list of sysex messages. scroll down for parameter lists. i too have been trying to figure this out for the past couple of weeks. it would be amazing to make a patch to edit in patches in more or less realtime (there is an editor for PC that does this already). cheers..

yes SYSEX is the answer....there is some sysex message that when sent to MPD24 it reset encoder, so basically it can be set to send sysex messages every time after +1 or -1 so we could finally can have endless encoder.

Just to figure out how to do it in pure data and it will be free, because other figure out how to do it in BOMES midi translator and it cost 50eur

any help would be appreciate

BUT ALL THIS FOR WINDOWS if its possible

here's the thread that i found useful:

http://puredata.hurleur.com/sujet-417-sysex

the main bit was:

"its working here gnu/linux with jack alsamidi.

[midiin] [midiout]

comma separated integer messages.

eg [240, 34, 26, 43, 253, 247(

on windows youll get messages the some midiobjects are not working.
But do your own testing some seems to work anyway."

i think i adapted that and got sysex to control my mks-50

i just got a matrix1000, and don't have any controller for it, so i might have to have a look at the sysex for that too. it should be the same as the matrix 6, i hope.

thank you! i've been trying for AGES to get Pd to communicate via sysex with my korg microkontrol and didn't realise sysexin / midiout would work.

One problem I encountered, however, was that not every piece of software and hardware recognises the decimal-formatted sysex output from Pd. Midi Monitor recognises it, for example, but Sysex Librarian doesn't, and neither does my microKontrol.

As a workaround, I'm routing the sysex output from Pd into a Max patch which contains a midiin object connected directly to a midiout: although the sysex data isn't being changed in any way, when it's sent out by Max it's recognised by all my software and hardware (including the microkontrol). It's a bit of a hack, but is relatively straightforward and means that i now have full in/out sysex functionality from Pd.

WinXP Pro SP3
Pd version 0.42-5
17-Jan-07 version of PortMidi

hey everyone,

I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found:

Patch (as attached:)

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
|
midiout

And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions)

Problem

The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247

and should convert have converted to HEX

F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7

instead, it comes out HEX

F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7

• with 3 wrong HEX pairs.

What happens

I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02

here's how it behaves in reverse engineering:

when i send DEC 0, 1, 2 or 3, it comes out HEX 0
when i send DEC 4, 5 6 or 7, it comes out HEX 1

see table:

DEC .. DEC -> HEX

00 .. 03 -> 00
04 .. 07 -> 01
08 .. 11 -> 02
12 .. 15 -> 03
16 .. 19 -> 04
20 .. 23 -> 05
24 .. 27 -> 06
28 .. 31 -> 07
32 .. 35 -> 08
36 .. 39 -> 09
40 .. 43 -> 0A
44 .. -> 0B

etc.

When you look at the BIN, it becomes obvious what's happening:

DEC (BIN) .. DEC (BIN) -> HEX (BIN)

00 ( 0) .. 03 ( 11) -> 00 ( 0)
04 ( 100) .. 07 ( 111) -> 01 ( 1)
08 ( 1000) .. 11 ( 1011) -> 02 ( 10)
12 ( 1100) .. 15 ( 1111) -> 03 ( 11)
16 (10000) .. 19 (10011) -> 04 ( 100)
20 (10100) .. 23 (10111) -> 05 ( 101)

.. two bits at the end are truncated.

It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message.

When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke.

Questions

1. can anyone confirm this?
2. is anyone currently maintaining PortMidi, so this could maybe get fixed?

thanks
groovelastig

http://www.pdpatchrepo.info/hurleur/sysex-conversion_vanilla.pd