Octatrack program change through Midihub

Hi guys, first of all sorry for the long and Octatrack specific post. I think the Cylvester guys are around, so maybe they can help.

I have a Model:Cycles slaved to an Octatrack and I would like to have the M:C patterns automatically changed when I manually change a pattern in the Octatrack. So for example when I load pattern A3 in octa, M:C loads A7.

M:C receives program change (programs 0-96), so I thought I could set a trig with CC transform, transforming an unused CC to program change, and locking a trig with that cc set to the value of the pattern I want to load in M:C. It actually works, but I would like to make this trig a manual trig (not playing always, just when I will change the pattern).

First i thought was to set it as a one-shot, so I can arm it with the “yes” button when desired. BUT, one-shots don’t work in midi tracks. Then I thought I could do this in an audio track, but cc audio out doesn’t work with locked values, only with knobs twisting.

So what I finally did, but don’t like it a lot, is having one trig in step 48 with the locked value of the pattern I want to load, and another trig in step 56 with the locked value of the pattern that is currently playing. So the program change is triggered in step 48 and corrected (current pattern selected again) in step 56. When I actually want the pattern to change, I press the trig in step 56 in order to delete it, and the pattern changes. It actually works, but not an ideal solution, as I have to reload the project if I want to have the trigs I deleted again.

So my question is if anyone has a good idea about how to achieve this :slight_smile: I know Octatrack sends program change with part, but that’s not an option for two reasons: first, I only have four parts per bank, and then, the program change happens one bar after it’s triggered :persevere:

Again, sorry for the brick, and thanks!

Hey, looks like Xform PC -> Stop, PC, Start tries to work around the same program change timing problem by sending a sequence of stop, program change and start messages. It will soon be possible to have Midihub perform the inserting ‘stop’ and ‘start’ messages at the right place, so it should hopefully help with timing of program changes in your case as well.

Is the mapping between the Octratrack’s progam number and the M:C program number unpredictable? How many such mappings do you intend to have in your set?

On a miditrack you can use a trig condition called “1st“, really handy for sending program changes, because they fire only the first time a pattern plays. Usually you dont want to keep sending the same pc message every time a pattern loops, because every time your synth is gonna reload the same pattern or patch, and that tends to cut off delay tails etc.

With the condition 1st you can for example trigger a note that you dont use often, really high or low G9 or C-1, pick one you like and with some midihub magic, you should be able to map velocity number to program change number and the start and stop messages, needed for correct timing.

BTW you can also send PC messages directly from the octatrack, you double tap the SRC button in a miditrack and set it with encoder C, confirm with yes and done

2 Likes

It depends on the set, but the idea is to have variable changes depending on the bank, so Octatrack a2 loads m:c b1 and b3 loads c4 (for example)

I know about the 1st conditional, the problem is that the program change will run once the pattern starts, so let’s say I want to run all the patterns in correlative order (Octatrack a1 with m:c a1, a2 with a2, and so on).

If I set the program change in Octatrack a1, first trig, and press play, the a1 in m:c will only load after the sequencer completes the first cycle. The program change will indeed execute in the first trig, but it’s too late for the m:c to load it, so has to wait one cycle, they won’t sync.

If I want to load a2 with a2, and I set the trig somewhere at the end of the Octatrack a1, it will send the program change as soon as it reaches the trig, and I don’t want it like that. The good conditional trig for this would be a “last” instead of “1st”. A trig that would detect when arm next Octatrack pattern, and would only run when this pattern change is “requested”.

Sorry if this sounds confusing, it’s probably easier than I explained :sweat_smile:

Also, I know about the program change option in the midi tracks. The problem is that it’s Part dependent, not pattern dependent, and you have 4 parts per bank. So if I have more than 4 patterns (I usually do), I’m limited there

I dont know the M:C but on my digitone if I send a program change, immediately followed by a stop and a start message, the pattern switch is instant. I used to do this with my gordius footcontroller, which I unfortunately sold a while back. It worked flawless. Lets hope we can do this with midihub soon as well

Sorry my ignorance, but if you send stop/start messages, doesn’t it actually stop and start the m:c sequencer? Wouldn’t it be some kind of sync mess?

Yes it does stop and restart the M:C sequencer, thats the point of start and stop messages. But really really fast. Midiclock keeps running as well, keeps stuff in sync.
You can try doing it by hand: on M:C make a long pattern 64 steps, while this is playing the first bar choose the next pattern, you can see the next pattern number blink for three more bars before it switches. If you hit during this waiting period the start and stop button at the same time, but the stop button a little tiny bit earlier ( just keep your middle finger a bit lower than your index finger) the pattern switches instantly. Midi is way faster than your fingers, so that works even better

Just read the other post, looks promising! When will this new feature be available?

We aim to release a small update this Friday. :wink:

3 Likes

Hi again! So I updated editor and firmware, and copied the program change example into my preset (which has a cc to program change transform just before), and it does work BUT not always. Sometimes the Model:Cycles still waits for the next cycle to change pattern :frowning: I’m attaching the preset (just first pipeline is the interesting one), in case there’s something wrong.

Thanks!

cc-to-pgm-v2.mhp (275 Bytes) cc-to-pgm-v2.mhp (275 Bytes)

1 Like

sorry double upload :smiley:

Do you send only a single CC message when changing the program? Twisting a CC knob can produce quite a lot of stop, pgm chg, start messages, the device might not be quick enough to handle it, as switching programs might not be immediate action. Program Change messages should ideally be only sent once to switch to the desired program numvber.

1 Like

Probably other ccs are sent in the same channel with lfos of the Octatrack… should I try disabling them?

No, as I guess they’re not CC 127, they don’t produce the program change messages. As long as there’s no bursts of CC on id 127 that get converted to program change, it shouldn’t be a problem. Maybe there must be some longer delay between the messages? In that case the other pipeline example, using the delay pipe, may be useful to solve it, but I’m just speculating. :slight_smile:

Tried with the delay, but not sure where to place it in my preset, maybe you can help

btw, funny thing: If i duplicate both the “Start” transform pipe and the “Stop” transform pipe (so there are two copies of each in a row), the failure ratio is much lower, like it fails approx 1/8, and without duplication is like 1/4. Maybe that helps you to find out why it happens?

Thanks!

1 Like

Let’s try to experiment using this preset: delayed_stop_pgmchg_start.mhp (1.1 KB)

Just change the input, output and output channel as necessary, and try playing with ‘delay time’ argument of Delay, to see if timing is affecting the success rate or not.

1 Like

Just tried. So if I set the delay time higher than 2ms, it always works, but there are sync issues, so not both patterns playing in perfect sync. If I set it to 1ms, sync is ok, but same issue than before -some changes are missed- :frowning:

What if we change the ‘Start’ into a ‘Continue’ message?

Just tried, sync is ok, but program change occurs after next cycle :frowning: