@whale-av said:

I think [bendout] is the object you are looking for.

Thanks, it works perfectly in Purr-Data.

This is my initial patch with your add:

midi2.pd

Soon I will study your link "Raw midi + midiout" to understand how to "fix" the microtonal informations in a midi file.

Bye,
a.

@oid How raw is [midiout].... ??
Did you establish that it cannot build a midi2 message...?
https://forum.pdpatchrepo.info/topic/13662/raw-midi-midiout

Just wondering because it can build NRPN... but does it have list constraints? RAW suggests "anything" in the message string that is just going to be converted to HEX.
It looks as though midi2 can carry both midi1 and midi2 messages, so maybe there is just one initial status byte to change.
David.

Hello,
Here is a quick reminder on how to generate raw midi in order to use the midiout object.

A question: is there another way to work with multiple midi ports, or is midiout the only one, pd vanilla.

bye

RawMidiBase.pd

I think I finally figured it out!
Well, not sure it solves all my problems, but at least here is a limitation of pd~: midi inputs and outputs (obviously)! There were a few of those in one of the libraries called by mybigpatch.pd (r_cycle).

So here is my way around it, in case it might help others:

• In the main patch, capture notein and send [notein $1 $2 $3( to [pd~]:
  
• in the pd~ subprocess, capture the incoming in an abstraction ./myfolder/notein.pd:
  
  and replace all instances of [notein] with [./myfolder/notein]
• similarly for noteout, an abstraction ./myfolder/noteout.pd to use in the pd~ subprocess:
  
  and replace all instances of [noteout] with [./myfolder/noteout]
• in the main patch, replace noteout with [r noteout]:
  
• and the same thing with ctlin, ctlout, bendin, bendout, midiin, midiout, etc.

And the command line magic trick (that it took me a while to figure out) in order to replace all this easily in all pd files:
$ sed -i 's+\(touchin\|polytouchin\|bendin\|notein\|ctlin\|midiin\|midiout\|noteout\|ctlout\)+'./myfolder/'&+' *.pd, which will prepend any instance of notein & co with ./myfolder/.

Improvement suggestions are of course welcome.
Cheers!

So here's what I'm thinking about. I'm not sure if this makes sense in Pd...

In SuperCollider, I can do:

s.boot;

(instrument: \something, midinote: 60, sustain: 2, amp: 0.7).play;

... and the sound comes from SC's own engine, based on a synth template named \something.

And I can also do:

MIDIClient.init;
m = MIDIOut(0).connect(0);

(type: \midi, midiout: m, midinote: 60, sustain: 2, amp: 0.7).play;

... and the same parameters midinote: 60, sustain: 2, amp: 0.7 are translated into MIDI noteon/noteoff messages, and performed by any MIDI software or hardware synth listening on that port.

A concrete benefit is: If I write some compositional algorithm and I want to decide later whether to play it within SC or using an external instrument, I don't have to change the composition logic at all. That part simply stuffs data into Event objects, and the event determines what finally happens.

In Pd, the data and the path the data take through the system are tightly coupled -- positional access to specific values is one way that this manifests, but more significantly, in a way, tight coupling is just the nature of dataflows.

So I'm wondering if this is a way to decouple: you could describe an action as a set of key-value pairs, forward the set to any event-player, and the event player would look up the data that it needs.

To some extent, you can already do this by discrete "key value" messages and [route]ing them into different parts of the player, but this isn't totally transparent: 1. If they are discrete messages, how do you know when the event is complete? Needs a sentinel. 2. [route] takes a little time to ignore irrelevant data (while a dictionary lookup would simply not look up irrelevant data). 3. If the pairs arrive out of order, math ops could be tricky, e.g. the following spits out a spurious 5 before the dog value comes through:

But with this hypothetical, you could control the order of access in the patch, instead of relying on well-behaved data:

This use case suggests that a dictionary should be lightweight, like a list, easy to pass around in the system (so, different from [text] or [array]). That matches up with jancsika's use cases (passing this type of dictionary into [expr] or getting it out of [soundfiler])... but it perhaps doesn't fit easily into the current message-passing scheme.

hjh

@Chip_Luxury-E.W.A You need to convert the hex to decimal and send it into [midiout]......

You are lucky, because [midiout] is Linux only.
David.

the oscillator and lissajous abstraction do work now with emscripten. the two object that do not work (at least for me at the moment) are [bang~] and [midiout], nothing works if they are part of the patch. [noteout] gets compiled, but i dont receive anything. and the issue with the fontsize and the linewidth and (perhaps) antialiasing of the lines...
would be great to have a small ([midiin] and) [midiout] example, if it is possible.

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

@redhexagonal I am no expert on midi (I don't use it), and I am not using Linux.
So..... a total guess.....
I believe reading the doc that [midiin] and [midiout] dump raw midi..... so no work is being done in Pd.
[notein] and [noteout] are doing work, and they are synced to the audio thread.
I would expect their latency to be the same as the audio.
But I am surprised if [midiin] and [midiout] are not also scheduled.

If Pd is doing no audio work, and the -noaudio switch is available on the RPI version of Pd, then you could reduce the audio buffer..... Delay (msec) to 1ms (or maybe even 0?) and hopefully have very little latency........
https://lists.puredata.info/pipermail/pd-list/2010-06/079469.html

That whole thread might help. There is some talk of using osc translation as well, but I cannot really see how that would help.
David.

I am building pd patches on a raspberry pi. I've noticed that (i think) all the midi objects other than midi and midiout seem to introduce a significant latency. A simple

• midiin > midiout

has a latency within puredata of about 7ms, but

• notein > noteout

has a latency of 29ms. Is this a known issue?