Good to know, thanks Justin. Maybe i was running an old OS. Or probably, my new midi cables and my new usb midi box have increased the stability.
The Octatrack has a cc number
CC 61 | Send request, 0 = all audio CC
that comes handy when using an external motorized controller to always keep the controller and octas parameters synced when working back and forth on both machines.
I`ve made a mapping for my BCF2000 to control both the Octa and my Machinedrum, and everything is working nicely with parameter feedback from both machines to the controller. However, without the aforementioned function that the Octa has its easy to end up out of sync (resulting in parameter jumps when turning the encoder to update to the parameters real value) on the Machinedrum.
I`ve tried finding the proper sysex message I can send the Machinedrum to make it send its parameters status to its output port, so the controller can receive it and update accordingly. Is this something I can do with this OS ? What command am I looking for?
I think this command in this OS will do what you want
(SYSEX init)|
$53 | Kit dump request ID
%0aaaaaaa | Send kit number %0aaaaaa ( 0 to 63 )
If kit number >= 64, the current unsaved kit data (workspace)
is sent.
But note that the data is sent as sysex so Iām not sure youāll be able to decode it without a computer in the chain
1 Like
Yes, you need to decode the current kit data in order to get the state of the MD parameters.
1 Like
Yep I thought that command looked like what I`d need, so I set up my controller to send:
$F0 $00 $20 $3C $02 $00 $53 $65 $F7
Is that right? I put >64 so that the MD should output its current value rather than the one saved in the kit.
But yes, the controller does not seem to respond to whatever data might be coming out of the MD, so having to decode the sysex (into what? midi cc?) for the controller to process seems needed.
Would it be possible to have a microcontroller of sorts doing this job? I mean; can I stick some chip in my controller that does the job of a computer? Maybe the MCL?
physical means are there; the question of firmware remains. Try it, perhaps?
I donāt have a MCL so can`t try that route; however, as far as I understand, the process using a computer would be as follows:
-send previously mentioned sysex string from BCF2000 as presets on the BCF is changed to the preset controlling the MD
-record MD`s outputted sysex string to computer
-translate sysex string to midi cc (?) and send back to BCF2000
Last step is where Iām lost; I have no idea what to do with the sysex message from the MD (and I might be skipping something here, I havenāt actually tried to record any sysex out from the MD yet, so I donāt know if the sysex command that I posted is actually working; altough when I did have a faulty/incomplete sysex command the MD would report āsysex errorā so I guess itās doing what it`s supposed to).
This might not be the best thread for this, not trying to derail the thread. Is there a chance that a future implementation of this OS could feature a CC request command (like on the Octatrack)? Would greatly ease this process, and I`m sure alot of people would find this function very helpful when using external (motorized) controllers with the MD.
Please stop using ` instead of ā if you want your post to look normal!
(Itās a pet peeve of mine, sorry)
1 Like
Looking forward to installing your OS and playing with SD2 once I get around to backing up.
A small tweak that would be neat to see:
Changing the values displayed when adjusting the āMonoā setting on the Rhythm Echo Delay so they show the
three actual settings (pingpong, mono, original).
Possibly just represented as 1,2,3 instead of the full midi range 0-127.
Quite unnecessary but it would still be neat if possible.
Thank you for making this!
1 Like
It would not be difficult to implement a SYSEX command to do this.
The question is whether itās the right approach.
Weād be dumping the parameters across all 16 tracks.
That equates to 16 * (24+1) = 400 CC messages.
or 400 x 3 = 1200 bytes of MIDI data.
Iād wonder if your controller could even handle that much dataā¦
ā
Or we limit it to a single trackā¦ 25 * 3 = 75 bytes.
1 Like
Thanks for your reply, Iām happy that itās possible. Problem regarding limited data bandwith makes sense. But if Iām correct, CC120-127 arenāt linked to anything afais. What if we used one cc# for each 4 machines? Say cc# 120 makes the MD send its controls for machines 1-4, cc#121 for 5-8 etc. Would that work?
Has anyone posted a video of the new snare in action?
1 Like
CC numbers 120 to 127 are reserved in the MIDI specification for other purposes. It would not be a good idea to have those sent around for other purposes in a MIDI system.
2 Likes
āThis video is privateā
1 Like
sorry now it should workā¦i posted the link before youtube was ready with the conversion. took agesā¦
1 Like
Sounds good! Is that M4L remote available somewhere?
yepp here Machinedrum Remote
the TRX-S2 implementation in the editor is coming in the next releaseā¦have to polish some things under the hood.
4 Likes
@Ess I sincerely appreciate yall even acknowledging this, being supportive, and even offering constructive criticism. Makes me have a lot of faith in yall doing the right thing, and adds respect for giving respect where itās due. Thank yall!
More details would definitely be appreciated. Are talking system corruption or speaker damage or ā¦?
1 Like