hello,
I would to know how pyramid can handle sysex messages :
1/ is pyramid able to record sysex messages received from midi din in?
2/ is pyramid able to read sysex messages and send them to midi din out?
3/ is pyramid able to import sysex messages stored in a .mid file?
4/ if yes, is pyramid able to handle sysex messages starting with "F0…3?
5/ and also, is pyramid able to handle sysex messages starting with "F3…3?
thanks a lot for your answers !
pyramid does not handle/process sysex.
the ‘only’ option it has is to pass sysex thru from input to output.
@Thibault_Squarp just seen a small typo in manual NO vs OFF 
thank you a lot for your quick answer!
I read the manual before posting but I wanted be sure
it seems no modern hardware sequencer can handle sysex 
I will probably buy the first one able to do, but unfortunately that will be not the pyramid 
Comparatively, it’s a steal otherwise… I think the other sequencers that can do similar things are in the thousands… and also don’t handle sysex.
yeah, few things will deal with sysex, as its just an amorphous blob of data.
usually, to do anything interesting with it, you really need to have a definition of it - but that differs for every synth. the other reason sequencer are unlikely to support, sysex messages can be of any length… thats not something you want for a ‘realtime’ instrument.
only thing I have that handles it well, is an electra.one (controller), but the ‘programming’ that requires kind of shows why its not a common thing, few musicians would actually use it.
really sysex is not designed for this kind of use-case, it was basicaly for data dumps (hence the unlimited length) - if you need it, then thats more an issue that your synth manufacture is abusing the midi spec.
(not uncommon, manufactures have had to workaround the many limitations of midi over the years)
so, unfortunately, i dont think you’ll ever likely find a sequencer supporting sysex… none, of my DAWs even support it (afaik)
what i would do is look for a something like a midi processor that can transform sysex into something thats more usable to any sequencer (not just the pyramid)
btw: F3 is not sysex, its a song select… only F0…F7 is sysex
the Fx family are collectively known as system real time or system common messages.
important to be clear, something supporting one, won’t necesarily support the other.
sorry for the confusing betwwen F1 and F3 messages 
yamaha rs7000 uses sysex to change some effects parameters or filters settings etc and its this groovebox I would like to be sequenced by a modern hardware sequencer. My akai mpc5000 is able to do without any issue that’s why I am surprised (as newbie) that newer sequencers are not able to do 
ableton don’t handle sysex but cubase does, I imagine that others daws able to do also ?
could you precise that you said about “something like a midi processor that can transform sysex into something thats more usable to any sequencer”? I’m really very curious about something that could help me to save my rs7000 
I use a BomeBox for SysEx, as in a specific Note (from my controller) or CC (from the Pyramid) forces the BomeBox (running MIDI Translator Pro) to calc and send out small SysEx messages to “do stuff” on some of my 90s romplers.
BomeBox would likely be overkill for just this application since it is very powerful but can be a demanding learning curve depending on your background/experience. (I use the Box to simplify my interface with the Pyramid)
Im under the impression that for short SysEx msgs one could use the MIDI Solutions Event Processor, but i do not have direct experience with that device.
There may be others.
That MIDI Solutions Event Processor looks like a fun little old-school box - you actually program it via SysEx messages, and while they do have a kind of editor software for it to help with programming, it mostly resembles Notepad by visual appearance 
It seems capable of mapping eg CC values into arbitrary position inside a SysEx of your definition, and other surprisingly deep stuff. AFAICS it doesn’t know about checksums though, which sadly renders it useless for me as all Roland synths have a checksum on SysEx data. Dunno about the RS7000, but if it doesn’t use checksums on SysEx data then this box might well do the trick. Depends on the exact needs of course.
what incredible device ! I never read something about sysex checksum for rs7000 so it could works, even I definitively needn’t wifi or ethernet connection 
same without network and cheaper would be perfect 
but I need to read about this device to know how it works exactly, because rs7000 uses also cc to control brightness, lfo parameters and lot of others, so I imagine I would have to find cc not used by the rs that could be use for sysex “transformation” …
Is latency of this converter good?
I will read about this device type, looking as good news
using Axoloti for sending SysEx messages (and converting other types of messages, e.g. CC, to them).
but it involves coding your own model-specific objects. (or rather taking existing objects and modifying to work with your specific hardware — nothing really complex if i can do that).
looks as something that could fix the issue ! thank you for the tip
if you decide to go Axoloti way, i have some CC-to-SysEx objects that you could modify to talk to your gear, so feel free to ask me.
so, you’ll be able to program CC messages in Pyramid, and Axoloti would convert them on the fly.
same with NRPN messages if you ever need them.
The problem with Axoloti is that it seems to be perpetually out of stock 
the reason I hesitated recommending a particular ‘midi processor’ to @transistor, is really depends upon (coding) experience e.g. Id hesitate to recommend Axoloti for this task, if you don’t have at least some coding experience.
if you have some coding experience perhaps you could code something for the retrokits rk002( I think its basically an arduino, in cable 
)
perhaps something like bomebox, MIDI Solutions Event Processor for non-coders.
(but check what sysex functionality they have up front.
unfortunatelyI know Blokas have said, doing sysex on the midihub is unlikely for reasons Ive detailed above 
@transistor
you’ll also have to know which sysex messages you need to send to the rs7000, and which to receive.
once you know the format of the sysex to send/receive its not too difficult.
well the rs7000 will not see the new cc, so its more down to not overlapping CC if you want to reuse the CC - however, probably the easier solution is to put these ‘new’ CC on a different midi channel.
since its very likely the rs7000 will not have a enough ‘spare’ cc’s, since this is probably why they have moved to sysex in the first place…
the only disadvantage of this approach, is on many sequences (incl pyramid) since the CCs are on a different midi channel to the notes - you’ll have to program on a different ‘track’
… so all a really a bit of a compromise, depending on what you want/need.
anyway its definitely possible, but Id recommend a route that you feel you are able to acheive… as I guess you probably don’t want to have to learn a ton of coding, to solve the issue
Chiming in here with Bomebox experience:
I don’t know what the SysEx messages for the rs7000 require, but I know for changing parameters on Emu gear which I do regularly, the BomeBox with MIDI Translator Pro handle it just fine. I regularly use 10 byte SysEx msgs to enact Transpose in realtime on an Emu Orbit whose values are calculated based on incoming MIDI data and a bit of logic. I also send out messages to turn on/off Channels (multi-timbral units) which if I remember correctly are short messages (same 10 bytes for Orbit, and I think 12 for the later romplers built on the Proteus 1000) but not in realtime (natch).
WRT ‘coding experience’, I’d caution that IMO MIDI Translator Pro isn’t a nice pretty pretty point and click icon driven interface and having a familiarity with MIDI data, messages, etc is extremely helpful. Bome support is freakin awesome and rivals Squarp, and there are always people around to help with scripts, but I’d characterise the software as more ‘functional’ rather than purty. (Not a negative - this was a selling point for me)
Many options!
Hopefully you don’t get overwhelmed, but despite which choices you make, there is assistance.
To be honest I would prefer not spend too much time in computer activity 
But as your ideas look as good solutions, I will give you more details to try to save my RS7000 
Firstly I checked empty control change, and finally I think there are enough available cc to achieve the main needs (cc 2 to 4, 8, 9, 12 to 15, 20 to 31, 33 to 37, 39 to 63 and some others are available, which seems enough to do interesting things)
So, in pattern mode, RS7000 has 64 “styles”, each style composed by 16 patterns, and each pattern has 16 tracks
Styles can be changed by song change message “F3 xx”, with “xx” value from 0 to 63 (to be converted in hexadecimal): this would be very nice to be able to convert song changes in cc messages, for example “F3 xx” converted to “CC 01 xx”
Then each pattern can be called by sysex messages as “F0 43 7E 00 xx 7F F7”, with “xx” from 0 to 15: this would also fantastic to be able to convert these sysex messages in a available cc, for example “F0 43 7E 00 xx 7F F7” converted to “CC 02 xx”
Is it possible possible with these devices? Easily? which one is the best to do?
Then, each track has 18 filter types that can be changed also with sysex, and so I would like to be able to sequence filter changes. The sysex message is “F0 43 10 6A 13 xx 41 yy F7”, with xx the track number and yy the filter type (number). This means 16*18= different values are needed to control filter type. If I well understand, I will need 3 CC to sequence all filter type changes (16 tracks * 18 filters types / 128 available values per cc = 2.25 rounded up)
Is it correct? and as previous question, is it possible?
Thank you so much for your help!
F3 will be less complex to implement that sysex
if your not already using program change and cc 0 (bank select) , you might find these fit more naturally to your use case. than cc1/2
no, you will simply need 16 cc’s
e.g.
say they were mapped to 20-36, and sent CC 24 = 12, then this would change track 5 to filter type 12.
note: your midi process could ignore values great than 16 (max filter type)
one thing you should be careful of here, is that the CC mapping is the thing you are going to sequence, so this has to ‘make sense’ and be easy to do in a sequencer. (otherwise, you’ll never actually use it )
another thing to consider…
is each rs7000 track on a separate midi channel? (do you want it to be?)
if so then things like that filter type, id use the same cc, but send it on the appropriate tracks midi channel - again, its about ‘ease of use’
which will work?
BomeBox - it sounds like this can do it… although @CreepyPants says its not ‘easy’ its still going to be easier than coding in C
MIDI Solutions Event Processor - theres no documentation, looks like you have to download their app to see if it can do what you need.
axoloti, rk002, arduino, etc etc
these can all do it, but i think all require some coding expertise, some more, some less.
if you have something like raspberry pi/organelle, these could also do it, and be programmed in Pure Data which is pretty straightforward.
If your not into coding, id recommend :
a) find a friend that is …
this is a very quick simple task, and you can work with them to decide which of about you go for (id be tempted with the rk002 )
b) check out the midi solutioins event processor, but I fear probably it wont do what you want, so the bomebox is perhaps the best option.
mod note: ive changed topic title to reflect direcion this topic has turned, as may be useful to others in the future.
It still seems weird to me that no HW sequencers “support” SysEx - because almost all HW uses it. I usually see explanations like “the message stream is too dense” or “programming it is too complicated” - but you don’t need to know how to program SysEx (nor even understand the message format!) in order to transmit and receive it. Tons of HW synthesizers - especially before the millennium - used it to send their knob/slider data. A sequencer need only receive the message on record, and send it back on playback. That’s it. The nuts and bolts can be entirely invisible to the user. This is how you e.g. get a filter sweep recorded on synths that don’t have dedicated CCs.
The exception is where you need to do some system-level commands that aren’t sent by the HW in question. Of course then you’ll have to dive deeper. But, for the common use case - recording a knob/slider - still weird to me that HW sequencers don’t do it. All my software sequencers do it and I rely on this every day. Still haven’t seen a convincing explanation why HW sequencers avoid it…the density of the stream is inconsequential for an embedded system in 2020. (It’s a 40 year old spec!).
its nothing to do with ‘too complex’, it’d be easy to code…
but sysex are the ‘wrong tool’ for parameter automation
(cc,nrpn, rpn are the standard for this)
some issues…
a) sysex are global messages, so they are not channelled.
most sequencers/daw use midi channel to decide how to route and associate ‘tracks’ to midi devices.
how can they do this for a ‘global’ message.
i guess, they could use the manufacturer id, but that means :
a) user has to now associate a manufacture id to a track - yuck!
b) you can only have one device from a manufacture on your midi network 
b) it be non-editiable
the best you could do, would be to record/playback the sysex, you wouldnt be able to ‘edit’ it, since the sequencer/daw has no idea what the data format is .
there are other issues, but these alone means - its not robust to support, and even if you do its not particularly useful.
so, its not wierd at all to me that hardware sequencers don’t support it , and indeed very few daws either.
anyway its a moot point… unless you plan on writing a sequencer
I hadn’t realized Pure Data can do something like that. Thanks for the tip!
I think most manufacturers include further device model information in there (so model X knows not to listen to model Y messages), plus an additional device ID that you can use to distinguish between multiple devices of the same model. Not that this contradicts your point, it only makes for a bigger yuck 