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.
Statistics: Posted by bsork — 05 May 2010, 16:13
]]>
Statistics: Posted by vic1iful — 05 May 2010, 15:53
]]>
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
Statistics: Posted by bsork — 21 Apr 2010, 13:13
]]>
Statistics: Posted by La Tenaille — 15 Apr 2010, 06:25
]]>
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.
Statistics: Posted by bsork — 14 Apr 2010, 08:38
]]>
Statistics: Posted by La Tenaille — 13 Apr 2010, 22:24
]]>
Statistics: Posted by senso — 12 Apr 2010, 21:51
]]>
]]>
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.
Statistics: Posted by senso — 11 Apr 2010, 09:08
]]>
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...
Statistics: Posted by bsork — 10 Apr 2010, 23:35
]]>
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!
Statistics: Posted by senso — 10 Apr 2010, 11:09
]]>
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.
Statistics: Posted by bsork — 10 Apr 2010, 09:59
]]>
http://fr.audiofanzine.com/sequenceur-d ... mc307.html
Statistics: Posted by nay-seven — 10 Apr 2010, 09:40
]]>
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.
Statistics: Posted by senso — 10 Apr 2010, 08:06
]]>
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...
Statistics: Posted by bsork — 10 Apr 2010, 00:48
]]>
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?
Statistics: Posted by senso — 10 Apr 2010, 00:07
]]>
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.
Statistics: Posted by bsork — 07 Mar 2010, 12:04
]]>