get midi data in a pd~ subprocess

[porres]

You currently can't get MIDI data from MIDI objects, such as [midiin], in a patch that is being run via pd~ as a sub process. I am assuming this is intentional, even though not well explained why or documented. Nonethelss, I'd expect it to happen.

I can see this should be kinda tricky if we're talking about the MAX external, but at least for Pd I would intuitively expect it to work so I can leave a feature request.

I wonder if there's a simple way of doing this by binding the midi receive symbols to a [pd~] object symbol that reroutes these messages. Because I tested that if you send, say, a "#mididin x" to [pd~], a [midiin] object loaded in the suprocess gets this "x" value message.

So, a function like inmidi_byte could check if there's a receive name according to a pd~ object and send it the midi message, and the pd~ object would then try to redirect it to "#mididin". I hope this makes sense.

[Spacechild1]

So, a function like inmidi_byte could check if there's a receive name according to a pd~ object and send it the midi message

I think pd~ would just need to bind itself to #midiin etc. and forward the messages to the subprocess.

That being said, I am not really in favor of this proposal. pd~ is just a filter, i.e. the subprocess only receives data (audio or messages) that is explicitly sent by the parent process. Since it has no access to the actual hardware audio inputs/outputs, I don't see why it should have access to the hardware MIDI inputs/outputs.

(IMO, it is a bit confusing that the subprocess sends/receives audio with [adc~]/[dac~]; it might have been conceptually cleaner to use [inlet~]/[outlet~] on the root canvas instead, but I can see how this would have complicated the implementation.)

I can see this should be kinda tricky if we're talking about the MAX external

Yes, that would be another argument against it.

[porres]

I don't see why it should have access to the hardware MIDI inputs/outputs.

I get the idea conceptually, but in real world usage, I have a bunch of patches that I need to split into some pd~ objects cause, yeah, I go crazy and CPU gets intense, and my laptops are kinda old...

and it gets pretty hard to manage this, that is, adapting the patch so all the controllers have to go on the parent patch and then send it to the subprocess and route that internally...

So even though there is a conceptual reason, I think there is a pretty good real world use case. Cause if you have [ctlin] objects in your patch, you'd expect them to work. In fact, as it is, all MIDI objects don't really work and there's no heads up for it the docs, so yeah, I was expecting them to work...

I think pd~ would just need to bind itself to #midiin etc. and forward the messages to the subprocess.

I ended up writting an abstraction that does this, so I get a bunch of MIDI messages and send to [pd~] so it works. Like I said here actually

Because I tested that if you send, say, a "#mididin x" to [pd~], a [midiin] object loaded in the suprocess gets this "x" value message.

So, It looks clumsy and I'd rather this just worked out of the box, basically.

[Spacechild1]

and it gets pretty hard to manage this, that is, adapting the patch so all the controllers have to go on the parent patch and then send it to the subprocess and route that internally...

IMO, it is just a matter of structuring your project appropriately. You already need to do this when using [pd~] for audio and messages, so what's the problem with doing the same thing with MIDI? I just don't see why MIDI should get a special treatment here.

[porres]

ok, we have one in favor, one against :) let's see if others chime in.

For the record, I was thinking of this wild idea that I tossed on the plugdata channel. I am envisioning a minimal plugin version that is basically just [pd~] compiled as a VST. I think I got something here and I'd like to pursue this. When loading the plugin, you'd have something like a prebuilt version with some basic configurations such as 2 audio channels in and 2 out... and you'd just need to tell it to find the Pd application in your computer. Voilá! Pd opens as a plugin in any DAW or host and you can use any external you wish as well. The way I see this, we could provide this in Miller's site along with the MAX external version.

The way plugadata and camomile works is that [adc~] and [dac~] behave the same as in [pd~], they get and send audio from this "super-process", which is a DAW or something. But they also get MIDI data in native objects, and [pd~] doesn't. Intuitively I was also making this relation when I felt that not dealing with MIDI was counterintuitive.

I know this is not actually related and should be a separate issue/request/idea. I also know I just have this faint idea without any detailed comprehension, but I thought I'd bring this up here.

I can see this should be kinda tricky if we're talking about the MAX external

I'd have to check how thingswork in MAX but besides being "tricky", or not the same, I have a feeling it should be similar and not too crazy or impossible (which would be a reason against it). It just means some more work. And the same thing could apply to the yet just a fantasy pd~ plugin version.

[Spacechild1]

I am envisioning a minimal plugin version that is basically just [pd~] compiled as a VST ...
and you'd just need to tell it to find the Pd application in your computer. Voilá! Pd opens as a plugin in any DAW or host and you can use any external you wish as well

This sounds a lot like https://github.com/jyg/PdVst

[porres]

btw, I'm creating a simple abstraction for else that sends midi to [pd~], and I am using it in yet another new abstraction that is a wrapper on [pd~] and makes things I bit more convenient. Worsr case scenario could be to add such a hack of a subpatch in the help file or something, which could be useful, but I'd still like MIDI to be supported and this be done internally (I could give it a try). I think a '-midi' flag could maybe be desired to enbale this feature