Pure-data: (feature) add flag to [sysexin] to make it return lists

[mariobuoninfante]

Currently when dealing with incoming sysex messages, you have to parse them byte by byte. Totally doable of course, but I was wondering if we could have a flag (ie [sysexin -l]) to make the object return a list.
In this way we can get rid of 12 objects.

[Jonathhhan]

You can also do it like that:

But I like the idea with the list argument (perhaps because it is also possible to output lists to [midiout]).

[mariobuoninfante]

absolutely, there are different solutions, but still I suppose there is some convenience in having the object itself dealing with that.
Also, this would match the behavior of [midiout] that since 0.48 (if I'm not wrong) accepts lists as well as single bytes.

PS in this screenshot I'm expecting [sysexin] to be connected to [inlet]

[Jonathhhan]

Perhaps it is not even necessary to parse them byte by byte? I always needed sysex as a list.

[mariobuoninfante]

well, that would be a breaking change that I suppose is not really needed.
Also there could be situations where you want to get the msg byte by byte. In the end, MIDI is a serial communication, so 1 byte at the time.

[porres]

I know the thread shouldn't be about the best way to patch this, but I think this is the most elegant one

[mariobuoninfante]

well, I have to say it is a good solution indeed.
But, I'm a "clean the list/array before using it" kind of person,
Probably this is not needed in this scenario since I don't think there is the possibility that [sysexin] skips a byte (ie malformed/incomplete sysex) - but I haven't double checked tbh.

[Jonathhhan]

also off-topic:
i used [textfile] because it is the fastest solution for very large lists. with smaller lists the difference does matter less (or not at all). with all methods you can also clear before using them.

[Spacechild1]

If you care about speed, use [array define] with a pre-allocated max. size. On my laptop, this is twice as fast as your [textfile] solution (18 ms vs. 36 ms)