Posti any comments, suggestions or whatever about the pack here.
I don't regard the pack as finished as I still have ideas to implement (but not that much time on my hands...): eg. variations on merging and distributing messages, and manipulating the piano roll.
midi utlity pack official thread
I'm currently building a Mackie Control emulator for Usine.
I realize how sysex manipulation can be tricky.
I think that some sysex tools can be very helpful...
- filter sysex messages,
- extract data's from a sysex flow,
- etc.
what do you think?
I realize how sysex manipulation can be tricky.
I think that some sysex tools can be very helpful...
- filter sysex messages,
- extract data's from a sysex flow,
- etc.
what do you think?
Olivier Sens
www.brainmodular.com
www.brainmodular.com
....eh, that's a tough one...
AFAIK, there's not much standarization in sysex messages. Only the start/stop bytes and a handful of bytes in the beginning with device numbers and such are defined as having a specific meaning . Some sysex messages aren't really "system exclusive" in the original sense though - some are even part of the MIDI specification. For instance (IIRC) both MTC and MMC are sysex messages.
I'm far from being an expert on sysex, but I suppose that there are ways of doing things that are if not universal, at least quite common. For example ways of coding values >127 into two or more data byte, and methods of computing checksums.
Will have to think about this one...
AFAIK, there's not much standarization in sysex messages. Only the start/stop bytes and a handful of bytes in the beginning with device numbers and such are defined as having a specific meaning . Some sysex messages aren't really "system exclusive" in the original sense though - some are even part of the MIDI specification. For instance (IIRC) both MTC and MMC are sysex messages.
I'm far from being an expert on sysex, but I suppose that there are ways of doing things that are if not universal, at least quite common. For example ways of coding values >127 into two or more data byte, and methods of computing checksums.
Will have to think about this one...
Bjørn S
the MMC MTC is already implemented in Usine.
I was thinking about simple tools.
Most of sysex have an Header, followed by data's followed by END_SYSEX. When we try to communicate with an hardware controller, we receive all the time the same type of message. like
[c]
F0 00 00 66 14 20 00 01 F7
F0 00 00 66 14 20 00 02 F7
F0 00 00 66 14 20 00 03 F7
F0 00 00 66 14 12 23 61 00 03 23 F7
F0 00 00 66 14 12 23 61 00 03 54 F7
[/c]
It could be great to have tools to:
1) filter incoming msg which the header fits a matching pattern like F0 00 00 66 14 20.
2) extract the binary data's like 00 03
And the inverse, be able to send easily sysex messages.
I was thinking about simple tools.
Most of sysex have an Header, followed by data's followed by END_SYSEX. When we try to communicate with an hardware controller, we receive all the time the same type of message. like
[c]
F0 00 00 66 14 20 00 01 F7
F0 00 00 66 14 20 00 02 F7
F0 00 00 66 14 20 00 03 F7
F0 00 00 66 14 12 23 61 00 03 23 F7
F0 00 00 66 14 12 23 61 00 03 54 F7
[/c]
It could be great to have tools to:
1) filter incoming msg which the header fits a matching pattern like F0 00 00 66 14 20.
2) extract the binary data's like 00 03
And the inverse, be able to send easily sysex messages.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
i confirm , I've users on the French forum who try to use hardware ( mc 307 ) sending sysex to control Usine , filtering and with array , yhey have some results , sadly i don't have more hardware sending sys ex to test..
here a post ( sorry in French )
http://fr.audiofanzine.com/sequenceur-d ... mc307.html
here a post ( sorry in French )
http://fr.audiofanzine.com/sequenceur-d ... mc307.html
I know MMC and MTC is already implemented, I just mentioned them because those were the first examples I could think of of sysex messages that aren't really "system exclusive".
Anyway, when I wrote my first answer, I didn't really think of the shorter messages like in your examples. When asked about sysex utilities, I immediately started to think of patch dumps and things like that, and the idea of generic utilities for those kinds of data is quite daunting.
However, something like your example shouldn't be too hard to do:
- search for pattern
- when pattern found:
- - filter/output the rest of the data up to but not including X last bytes. (X because some messages will always contain some extra data like checksums before the ending F7.)
The resulting data (00 03 in your example) could well be output as a single value in many cases, but I reckon that the coding would have to be done especially for each device to be meaningful.
Anyway, when I wrote my first answer, I didn't really think of the shorter messages like in your examples. When asked about sysex utilities, I immediately started to think of patch dumps and things like that, and the idea of generic utilities for those kinds of data is quite daunting.
However, something like your example shouldn't be too hard to do:
- search for pattern
- when pattern found:
- - filter/output the rest of the data up to but not including X last bytes. (X because some messages will always contain some extra data like checksums before the ending F7.)
The resulting data (00 03 in your example) could well be output as a single value in many cases, but I reckon that the coding would have to be done especially for each device to be meaningful.
Bjørn S
you're right, for the resulting data's, it's hard to imagine a general conversion tool.
it can be a complex packed fields, including -
track number, fader position, track name, SMPTE, integer lo+hi part, etc... often mixed together...
Maybe we can start to list most of basic cases ?
Also I'm sure that the Midiin module sysex management can be improved.
I'm open to all suggestions!
it can be a complex packed fields, including -
track number, fader position, track name, SMPTE, integer lo+hi part, etc... often mixed together...
Maybe we can start to list most of basic cases ?
Also I'm sure that the Midiin module sysex management can be improved.
I'm open to all suggestions!
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Guess I have to start with taking a closer look at the sysex specifications for my own equipment, then? Maybe even dig out some older boxes I haven't been using for ages, just to get an impression of how different manufacturers handle these things. That is - if they use sysex at all. I'm not sure. I do use a little bit of sysex coding in my own setup, but that is only to set the behaviour of an audio switcher and a midi router, so nothing fancy or complicated at all. Resend when necessary, that's about it.
If we start with collecting info of shorter messages that can be identified by byte patterns and define a set of rules the resulting data can be handled, I think we're on the way to something. I can't really think of any way this can be done very user friendly though, unless it's coded for a specific device or family of devices. But of course, creating specialized patches/scripts doesn't rule out more generic solutions that may have to modified a bit from case to case, but at least it's a start.
Except for the above mentioned setup sysex messages, I must admit that I haven't been using sysex at all in Usine, and I'm not sure if I have ever tried to get sysex in at all. I suppose you've stumbled across some troubles working with the Mackie emulator (and apparantly someone else with an MC307 has had troubles too). What is the problem? Large chunks of data choking the MIDI input or the sysex array? Lost data? Something else? Just curious, as always...
Maybe even dig out some older boxes I haven't been using for ages, just to get an impression of how different manufacturers handle these things. That is - if they use sysex at all. I'm not sure. I do use a little bit of sysex coding in my own setup, but that is only to set the behaviour of an audio switcher and a midi router, so nothing fancy or complicated at all. Resend when necessary, that's about it.If we start with collecting info of shorter messages that can be identified by byte patterns and define a set of rules the resulting data can be handled, I think we're on the way to something. I can't really think of any way this can be done very user friendly though, unless it's coded for a specific device or family of devices. But of course, creating specialized patches/scripts doesn't rule out more generic solutions that may have to modified a bit from case to case, but at least it's a start.
Except for the above mentioned setup sysex messages, I must admit that I haven't been using sysex at all in Usine, and I'm not sure if I have ever tried to get sysex in at all. I suppose you've stumbled across some troubles working with the Mackie emulator (and apparantly someone else with an MC307 has had troubles too). What is the problem? Large chunks of data choking the MIDI input or the sysex array? Lost data? Something else? Just curious, as always...
Bjørn S
There is no real problem for sysex manipulation, except that it's heavy.
Also I realize that Usine doesn't handle bit manipulation like
shr, shl, bit and, bit or, bit xor, bit not etc...
I made them by script but I'm sure that a bit manipulation pack can be helpful.
Also I realize that Usine doesn't handle bit manipulation like
shr, shl, bit and, bit or, bit xor, bit not etc...
I made them by script but I'm sure that a bit manipulation pack can be helpful.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
yes it's easy for a programmer, I've made several patches to do that.
I'll try to compile them into a pack.
I'll try to compile them into a pack.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
La Tenaille
- Member
- Posts: 547
- Location: Saint Etienne (France)
- Contact:
if one day Usine and your FC300 talk together Bjørn, I'd be delighted to steal your work 
Well, I have one big patch (still only V4) set up to use the FC as some sort of re-assignable MIDI controller. I'm using the CC mode of the pedal, with all the switches sending 127 when depressed and 0 when released. That way I can re-interpret the CCs to act similar to buttons (momentary/trigger), switches (toggle on/off) or as bass pedals without a UI mismash of MIDI learned controls. I'm not sending anything back to the FC though, so the biggest drawback with this setup is that I don't get any visual feedback from the LEDs.
As soon as I get my head above water with other stuff, I guess it's time to rework this patch and use even more scripting to make it a little less messy. The main parts are already based on scripting, but with the new, improved scripting engine I can do so much more without running into trouble. Then I will make another try at understanding the sysex needed to control the LEDs (and maybe even the LCD!) of the FC to give a visual feedback where it's more comfortable for a shoegazer like yours truly.
When I get that far, I will try to make a more generic version of the patch and put it up as an add-on. As it is (and I guess I'm not going to change that), sub-patches etc only relevant for me and my setup is mixed in with everything else.
As soon as I get my head above water with other stuff, I guess it's time to rework this patch and use even more scripting to make it a little less messy. The main parts are already based on scripting, but with the new, improved scripting engine I can do so much more without running into trouble. Then I will make another try at understanding the sysex needed to control the LEDs (and maybe even the LCD!) of the FC to give a visual feedback where it's more comfortable for a shoegazer like yours truly.
When I get that far, I will try to make a more generic version of the patch and put it up as an add-on. As it is (and I guess I'm not going to change that), sub-patches etc only relevant for me and my setup is mixed in with everything else.
Bjørn S
-
La Tenaille
- Member
- Posts: 547
- Location: Saint Etienne (France)
- Contact:
great project ! My use of the FC300 is very basic, so any improvment would be great for me
@La Tenaille and other FC-300 users.
Last night I started to investigate the SysEx mode of the FC, and managed after a bit of fumbling to send some data to it that worked. The manual is a bit vague on some points, so it took some experimenting.
The pedal can to various degrees receive and send SysEx in other modes, but the great thing with this mode is that the controls themselves (the switches and pedals) are totally independent of the visual feedback, (hopefully) making it ideal for external control (ie Usine). I guess I could use one or two of the other modes as well, but SysEx seems to most practical and flexible.
I will still need some time to investigate how the FC reacts to certain types of data before I settle on a scheme for how I want to code a script, but here are some preliminary ideas of how the different parts can be used:
* Bank/Number display shows the currently selected conductor scene or preset number; flashing in some way when another number has been selected, but not yet recalled.
* The LCD's first line shows the currently selected scene or preset - maybe alternating when new is selected but not recalled. The second line shows the caption of the last used control.
* The DOWN/UP moves through the scenes or presets, while CTL1 recalls them. CTL2 is used to switch between pedals 1-5 and 6-10 with the LED on for 1-5. The LEDs for DOWN/UP and CTL1 I'm not sure about. Maybe blinking when the synchro is running (cycle, bar, beat), unless it's too slow or unstable to be of any practical use...
* The switches 1/6-5/10 and the two pedal switches can act either as momentary or latching switches or as triggers. When latching, the corresponding LED should light up, but for the two others I don't see much point in that, unless it's for being in sync with the corresponding interface object. Maybe some sort of blinking to tell the current mode?
* The pedals should work as per normal - not much to do but read the data anyway - but I guess I'll keep my old idea of having them generate two data streams out, where one can be "inverted" so it's easy to connect for crossfadings and suchlike.
I haven't got any plans of including any (working) code for the external switches or pedals or the amp control outs, but I hope I will end up with something that will make that easy to add if/when someone is interested. I also hope the end result could be of use with other Roland/Boss/Edirol controllers as well without too much editing.
Any ideas or comments?
PS Yes, I know this post is off-topic as a specialized script/patch like this has nothing to do in the utility pack, but it's my thread, so there! DS
Last night I started to investigate the SysEx mode of the FC, and managed after a bit of fumbling to send some data to it that worked. The manual is a bit vague on some points, so it took some experimenting.
The pedal can to various degrees receive and send SysEx in other modes, but the great thing with this mode is that the controls themselves (the switches and pedals) are totally independent of the visual feedback, (hopefully) making it ideal for external control (ie Usine). I guess I could use one or two of the other modes as well, but SysEx seems to most practical and flexible.
I will still need some time to investigate how the FC reacts to certain types of data before I settle on a scheme for how I want to code a script, but here are some preliminary ideas of how the different parts can be used:
* Bank/Number display shows the currently selected conductor scene or preset number; flashing in some way when another number has been selected, but not yet recalled.
* The LCD's first line shows the currently selected scene or preset - maybe alternating when new is selected but not recalled. The second line shows the caption of the last used control.
* The DOWN/UP moves through the scenes or presets, while CTL1 recalls them. CTL2 is used to switch between pedals 1-5 and 6-10 with the LED on for 1-5. The LEDs for DOWN/UP and CTL1 I'm not sure about. Maybe blinking when the synchro is running (cycle, bar, beat), unless it's too slow or unstable to be of any practical use...
* The switches 1/6-5/10 and the two pedal switches can act either as momentary or latching switches or as triggers. When latching, the corresponding LED should light up, but for the two others I don't see much point in that, unless it's for being in sync with the corresponding interface object. Maybe some sort of blinking to tell the current mode?
* The pedals should work as per normal - not much to do but read the data anyway - but I guess I'll keep my old idea of having them generate two data streams out, where one can be "inverted" so it's easy to connect for crossfadings and suchlike.
I haven't got any plans of including any (working) code for the external switches or pedals or the amp control outs, but I hope I will end up with something that will make that easy to add if/when someone is interested. I also hope the end result could be of use with other Roland/Boss/Edirol controllers as well without too much editing.
Any ideas or comments?
PS Yes, I know this post is off-topic as a specialized script/patch like this has nothing to do in the utility pack, but it's my thread, so there! DS
Bjørn S
Would one of these make the job easier. Good news about the FC. Nice work. http://www.kissbox.nl/products_new.html
Hi, looks like the KissBox stuff could be interesting in some setups. Never heard of it before, so thanks for sharing.
As mentioned in this topic, I'm pretty sure that I've decoded the parts of the FC's sysex implementation that is interesting at first. Some messages I haven't bothered with, and bulk dumps aren't of any interested anyway. What I'm dealing with now has more to do with workflow and how one would like the pedal to operate. In can be done very complicated with a lot of timers and multifunctions etc, but I don't think it's a good idea to take that direction too far. My first effort will be something similar to the above points, but with some minor adjustments and some hardcoding just fitting for my own setup, but I will post it when I have the core of it in place so others can test whether the ideas have some relevance for them, and we'll take it from there.
As mentioned in this topic, I'm pretty sure that I've decoded the parts of the FC's sysex implementation that is interesting at first. Some messages I haven't bothered with, and bulk dumps aren't of any interested anyway. What I'm dealing with now has more to do with workflow and how one would like the pedal to operate. In can be done very complicated with a lot of timers and multifunctions etc, but I don't think it's a good idea to take that direction too far. My first effort will be something similar to the above points, but with some minor adjustments and some hardcoding just fitting for my own setup, but I will post it when I have the core of it in place so others can test whether the ideas have some relevance for them, and we'll take it from there.
Bjørn S