Osc support (2nd try) #514

piegamesde · 2019-10-11T18:08:00Z

As of #513, I hacked together a prototype for OSC support. It compiles on my system, and it won't compile any of the modules I don't currently use (fixing them is not that much work, just simply change the header). It hasn't been tested yet.

Everything that is related to MIDI, but not unique to MIDI has been renamed to form a new "Event" API.
The old API is still available using header files (typedef for the win).
- Internal code must use a new JackMidi.h that does the type renaming. I could have kept all the old header files so that all the remaining code still works, but I didn't like the idea of having a dozen of almost empty files in the code base.
The MIDI channel type has been complemented with an OSC one
I'm not sure about the MIDI-specific things. Especially the MIDI drivers, since I don't see any equivalent for not-hardware-driven protocols like OSC
Net support is not clear at all. I'd like to pass all event ports using the existing MIDI code since changing the headers would break things between JACK versions I can't simply make backwards-compatible.

Feel free to object any of the design decisions.

Except the raw MIDI queues, since they're MIDI specific

Documentation saying that they are deprecated is missing

falkTX · 2019-10-11T18:23:23Z

This is quite nice!
Thanks for all the work so far.

Curious, how are bundles going to be handled here?

Can you add an example tool that uses this renamed API for OSC?

piegamesde · 2019-10-11T20:10:56Z

Curious, how are bundles going to be handled here?

I thought I'd keep it simple: JACK is only the transport server and does not parse the sent data at all. This is the current behavior with MIDI (granted a few exceptions) and I'm not sure if I should change this. Clients may or may not send message bundles. They will be treated as event messages as any other message by JACK. Clients should make sure their messages are not too large (maybe we should increase the default buffer size?). Since each OSC event has its own time stamp system, event order for bundles is not that important.

Can you add an example tool that uses this renamed API for OSC?

Should I put it into the example_clients folder or should I rather create a new repository for it?

I cannot test this locally due to lack of hardware

I don't know how useful it is yet, maybe I'll remove it later on (tell me if you don't like it)

falkTX · 2019-10-11T20:52:32Z

I thought I'd keep it simple: JACK is only the transport server and does not parse the sent data at all.

That makes a lot of sense actually, I am quite okay with this.
It is different from what the previous jack_osc project does, but that is quite fair.

Should I put it into the example_clients folder or should I rather create a new repository for it?

In the examples folder, I think such a tool could be the go-to example way of doing things.
I imagine something simple that puts jack osc messages into a ring buffer, and then passes them off to the network via liblo. CLI arguments define the protocol to use (UDP vs TCP) and the port.
jack_midi_dump can serve as an example as it uses a ring buffer to print messages out of the RT process function.
what do you think?

x42 · 2019-10-11T21:10:38Z

common/jack/midiport.h

+
+
+/** A Jack MIDI event. */
+typedef jack_event_t jack_midi_event_t;


This needs to be the other way 'round.
For ABI compatibility the library needs to expose the jack_midi_event_t symbol.

Aw, crap. Are you sure there isn't a way to make this work? Do I have to redo all my renaming work or only the header files in common/jack?

yes indeed. having the macros makes it API compatible, but not ABI.
the MIDI functions need to be actually defined. they will be just calling the event API, but they need to be there for visibility and backwards compatibility

You could write wrapper functions and export those.

This implies that jack/eventport.h must include jack/midiport.h. So we are going to be stuck with the old headers always included until the next major version bump :(

It is the other way around. midiport.h needs to include eventport.h and define the types in a way that keeps backwards compatibility.
clients built against new jack need to work with older jack and vice-versa, the exception being if a client uses the new API not available on the older versions (obviously)

The "vice-versa" part in particular. say you have an old, closed-source JACK app. You cannot re-compile it. That still needs to work with modern JACK.

That app might be bitwig, or might be baudline,..

JACK's ABI has been stable since it's first release and is not versioned (not even major versions break the binary interface).

I may need help on this one, I'm lost in the C header hell with obscure compiler messages

piegamesde · 2019-10-11T21:33:27Z

@falkTX I got a few ideas for useful OSC tools. I think I'm going to start with as simple MIDI->OSC->MIDI bridge and escalate as needed. Would you mind the example being in Rust?

falkTX · 2019-10-11T21:35:31Z

Actually yes. rust does not build for all the targets that jack does, so using rust would be quite limiting.
Please stick to C or worst case C++.

beatboxchad · 2019-10-11T22:47:16Z

I'm sold. \m/ nice going, this kinda rules!

common/JackEventAPI.cpp

ventosus · 2019-10-12T08:18:36Z

Hi

There currently are at least 2 projects already doing OSC via JACK, afaik.

zynaddsubfx (stable)
synthpod (unstable)

They just reuse the JACK MIDI ports and API unchanged. To discriminate OSC ports from JACK ports, they are tagged with metadata. The port metadata has been defined by @drobilla at a LAC some years back [1]:

"http://jackaudio.org/metadata/event-types" "OSC"

Some of those metadata keys seems to have been imported into JACK2 source, but not all, it seems @falkTX ?

This does not break anything and is backwards compatible to the beginning of JACK, because OSC and MIDI can coexist on the same event port:

First byte of OSC is either '/' or '#', both are no valid first MIDI byte. So a application handling only MIDI messages, will just ignore OSC and vice-versa.

So, a new event port is really not needed, imho and tagging ports with the correct metadata is super simple.

It also has the advantage that it is easier to extend. e.g. say I want to route LV2 atoms via JACK ports (I've actually done that), I only need to define a new metadata key and make sure that the first byte does not clash with either MIDI or OSC. Going the dedicated-event-port-per- event-type-route, this will always need a new JACK release and be backwards incompatible.

If there really should ever be the need for a new event port type, then please take inspiration from LV2 and create an event port type for all possible future event types and extend the event structure with a proper type, will make any further request for new port types superfluous:

typedef struct _jack_event_event
{
       	jack_nframes_t    time;   /**< Sample index at which event is valid */
    	size_t            size;   /**< Number of bytes of data in \a buffer */
            uint32_t        type;  🌹*<Type of this event */
    	jack_event_data_t *buffer; /**< Raw MIDI data */
} jack_event_event_t;

[1] https://github.com/drobilla/jackey/blob/master/jackey.h

ventosus · 2019-10-12T08:34:01Z

zynaddsubfx has a simple header with some macro definitions[1] and then just uses that [2] + tagging the port with the proper metadata [3].

[1] https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Nio/jack_osc.h
[2] https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Nio/JackEngine.cpp#L320
[3] https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Nio/JackEngine.cpp#L249

piegamesde · 2019-10-12T09:22:47Z

@ventosus This is cool. My goal is to be fully backwards compatible to existing solutions like these. I am probably going to remove the different port types soon. The only thing I don't like is having to be "MIDI-compatible" regarding the start byte. If the metadata things works properly, we can rely on our patchbays to warn from accidental port content mismatch.

ventosus · 2019-10-12T09:37:51Z

@ventosus If the metadata things works properly, we can rely on our patchbays to warn from accidental port content mismatch.

Now that JACK2 finally has metadata support, too, more projects could actually use this, yes.

Instead of warning, patchbays should just refuse to connect differing event ports (jack_connect could be adapted as an example). patchage [1] does already do that since years, iirc (when run on JACK1, because JACK2 is a late adopter of metadata :-). patchmatrix [2], too.

[1] http://drobilla.net/software/patchage
[2] https://open-music-kontrollers.ch/lad/patchmatrix/

@x42

@x42 Will this work? I am not confident about this

ventosus · 2019-10-12T10:03:34Z

@piagemesde

If there's no new event structure, no a new port type, an additional header (e.g. jack/eventport.h) with some defines and typedefs like [1] would be enough, imho (e.g. just replace osc with event).

[1] https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Nio/jack_osc.h

There are only two now, `gAudioPortType` and `gMessagePortType`. There is a string constant for `JACK_DEFAULT_MIDI_TYPE` which will be handled separately.

ventosus · 2019-10-12T10:22:08Z

last time I checked, JACK OSC messages were not routed via either netjack1, netjack2 or both ?

Needs some investigation, I guess...

- Added inline helper methods to create ports of the correct type - Had to move `jack_port_uuid` to the top because we still can't use methods declared below in 2019 - I'd like to add helper methods that automatically set the metadata but C has no method overloading?! - Improved metadata documentation - Registering a port with the `JACK_DEFAULT_MIDI_TYPE` will automatically change it to `JACK_DEFAULT_MESSAGE_TYPE` for forward compatibility.

piegamesde · 2019-10-12T11:53:23Z

@ventosus If I just add a new header, this means that we will stick internally with processing "MIDI" even if in reality the buffers may contain all sorts of data. I fear that this will lead to confusion or even bugs.

Honestly, I have no clue how to update netjack while keeping backwards compatibility. We can rename the MIDI ports to message ports with ease, but a) I don't know how MIDI-specific the data handling is here and b) I don't know if netjack handles metadata yet.

piegamesde · 2019-10-12T14:19:23Z

@x42 Please have a look at piegamesde@8614e5d. I redid that commit (with slightly different naming) from scratch to get a proper diff.

piegamesde · 2019-10-12T15:09:35Z

@ventosus Do we really need JACK_METADATA_EVENT_TYPES to be able to contain multiple values? This is quite a pain to process, honestly, and I don't really see the use (you could still split up the port to one per protocol, or only tag the most prominent one).

ventosus · 2019-10-12T15:15:19Z

@ventosus Do we really need JACK_METADATA_EVENT_TYPES to be able to contain multiple values? This is quite a pain to process, honestly, and I don't really see the use (you could still split up the port to one per protocol, or only tag the most prominent one).

@piegamesde probably not (and the linked projects don't do that, either). @drobilla as the author of that key may remember the rationale for it, I don't remember, sorry.

drobilla · 2019-10-13T18:50:06Z

It's for multiplexing. Though it's slightly more annoying to deal with the metadata, this is nothing compared to having to deal with a bunch of separate event ports of different types, compared to a single one with a well-ordered sequence of events. Aside from being a massive hassle to deal with in a sample accurate context, many ports is also quite a bit slower.

This way you can also extend an app to support OSC (or whatever) without completely breaking its interface or making routing weird, because you can naively route around the "control events" without really having to care what they are.

Generally speaking, this stuff is trying to pretend that event ports are the way they should have been: a sequence of time stamped whatevers. I agree it's not pleasant, but c'est la vie.

piegamesde · 2019-10-13T21:52:25Z

@drobilla So I'm going to write something to check port compatibility, hide the ugliness in helper methods. What are the semantics of an output port having multiple protocols? As I understand it, that port may emit events in any of those.

Say I have a port that may send OSC and MIDI data. Can I connect this to OSC ports or must these ports implement both OSC and MIDI as well? I'd think the latter one, because that's how you do type safety in programming languages. (Does this matter anyway? Are there even ports that can send both MIDI and OSC?)

piegamesde · 2019-10-17T09:16:30Z

@drobilla Instead of allowing multiple values in this field, what about defining one value that has the meaning of "any protocol"? You'd still be able to do multiplex routing MIDI and OSC into one port, but without the pain of having to handle a list of elements.

drobilla · 2019-10-19T19:30:14Z

But then you can't tell what it supports (this is also roughly how it works in LV2). I get that it's mildly more annoying to use than simple one value properties, but.... oh well? I don't think the few lines of C that it takes to look for something in a list outweighs the actual usefulness.

It's a compromise because metadata keys can only have one value. Since this is the general way you deal with that, some utilities for it will probably come in handy anyway.

An output port that has both may send both.

I'll try to actually read this branch in detail tomorrow and hopefully get a better idea of how this ties in with the metadata stuff.

piegamesde added 13 commits October 11, 2019 14:32

Rename all JackMidi* files to JackEvent

f6939c6

Rename Midi API to Event API

e2c5a09

Rename JackMidiPort to JackEventPort

c325c97

Update type names in JackMidiUtil

fb648d2

Add OSC port type

d011917

Add OSC namespace property

90b8043

Rename all the queues

8aa1e1a

Except the raw MIDI queues, since they're MIDI specific

Update JackMidiDriver

b695770

Update JackNet

0c1c32d

Update build script

e39a37d

Fix remaining compile errors

e949f54

Add typedefs for backwards compability

125b3ce

Documentation saying that they are deprecated is missing

Make linux modules compile

1e18408

piegamesde added 2 commits October 11, 2019 22:32

Fix more compile errors

eb1ad87

I cannot test this locally due to lack of hardware

Add generic event port type

52ab82d

I don't know how useful it is yet, maybe I'll remove it later on (tell me if you don't like it)

x42 reviewed Oct 11, 2019

View reviewed changes

beatboxchad reviewed Oct 11, 2019

View reviewed changes

common/JackEventAPI.cpp Show resolved Hide resolved

piegamesde mentioned this pull request Oct 11, 2019

Port type discussion #515

Closed

piegamesde added 2 commits October 12, 2019 11:49

Hopefully make it ABI compatible

8d9c141

@x42 Will this work? I am not confident about this

Fixed another Mac compile error

c4904f1

Remove previously added port types

1c3f811

There are only two now, `gAudioPortType` and `gMessagePortType`. There is a string constant for `JACK_DEFAULT_MIDI_TYPE` which will be handled separately.

Update jack_connect client

613174d

mxmilkiib mentioned this pull request Nov 2, 2019

JACK MIDI/OSC/CV backend cbdevnet/midimonster#30

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Osc support (2nd try) #514

Osc support (2nd try) #514

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

x42 Oct 11, 2019

piegamesde Oct 11, 2019

falkTX Oct 11, 2019

x42 Oct 11, 2019

piegamesde Oct 11, 2019

falkTX Oct 11, 2019

x42 Oct 11, 2019

piegamesde Oct 11, 2019

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

beatboxchad commented Oct 11, 2019

ventosus commented Oct 12, 2019 •

edited

ventosus commented Oct 12, 2019

piegamesde commented Oct 12, 2019

ventosus commented Oct 12, 2019 •

edited

ventosus commented Oct 12, 2019

ventosus commented Oct 12, 2019

piegamesde commented Oct 12, 2019

piegamesde commented Oct 12, 2019

piegamesde commented Oct 12, 2019

ventosus commented Oct 12, 2019

drobilla commented Oct 13, 2019

piegamesde commented Oct 13, 2019

piegamesde commented Oct 17, 2019

drobilla commented Oct 19, 2019 •

edited



		/** A Jack MIDI event. */
		typedef jack_event_t jack_midi_event_t;

Osc support (2nd try) #514

Are you sure you want to change the base?

Osc support (2nd try) #514

Conversation

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piegamesde commented Oct 11, 2019

falkTX commented Oct 11, 2019

beatboxchad commented Oct 11, 2019

ventosus commented Oct 12, 2019 • edited

ventosus commented Oct 12, 2019

piegamesde commented Oct 12, 2019

ventosus commented Oct 12, 2019 • edited

ventosus commented Oct 12, 2019

ventosus commented Oct 12, 2019

piegamesde commented Oct 12, 2019

piegamesde commented Oct 12, 2019

piegamesde commented Oct 12, 2019

ventosus commented Oct 12, 2019

drobilla commented Oct 13, 2019

piegamesde commented Oct 13, 2019

piegamesde commented Oct 17, 2019

drobilla commented Oct 19, 2019 • edited

ventosus commented Oct 12, 2019 •

edited

ventosus commented Oct 12, 2019 •

edited

drobilla commented Oct 19, 2019 •

edited