Sending Bank Change and Program Change


#1

Total n00b on the Pyramid, here.
Apologies if I’m misunderstanding something.

Scenario: Working with Elektron Octatrack and Pyramid, sending a Bank Change and Pgm Change from Pyramid to the OT to control OT Pattern Selection.

OT uses MSB=0 for Pattern Banks A-H and MSB=1 for Pattern Banks I-P

On the Pyramid, using Step Mode, creating an MSB Bank Change for Bank 0 and Pgm Chg 1 on Step 1 and on Step 9 I create an MSB Bank Change for Bank 0 and Pgm Chg 1 (Which is OT Patterns A01 and I01 respectively).

Step01: MSB Bank = 0; PgmChg 1
Step09: MSB Bank = 1; Pgm Chg 1

The Pyramid does not send the Pgm Change if it is the same Pgm as the previous regardless of the Bank Change in between.

If the Step 9 Pgm Change is a number OTHER than the previous Pgm Change, it will send both the Bank Change and the Pgm Change. (Data monitored via MIDIOx)

Am I missing something?
It would seem the engineers figured it’d save some of the MIDI traffic to only send data that indicates a change in state, and most synths would respond to a Bank Change without PgmChg responsibly.

Note: BTW - the workaround to get stuff sync’d for instant pattern change on the OT is to alter the Bank/PgmChg MIDI data to stop and restart the sequencer, which is easy to do with a software sequencer and translator in a test situation. All works as expected in those circumstance, but the lack of expected results replacing the software sequencer with the Pyramid led to the above conclusions/issues.


#2

I have made a similar experience with the internal BPM effect. There seems to be some sort of inconsistency…changes on the first step get lost so easily, my workaround for the last live-set was to use microsteps and alter BPMs twice on the first beat, but I guess it wouldnt be a good idea for program changes, cause this could create some unwanted sounds…


#3

Thanks for your response & sharing your workaround.
I haven’t tried microsteps yet.


#4

Yeah, why not giving it try …I don’t have an OT, so maybe the program changes are as quick to be inaudible.


#5

well, the workaround is tougher for the OT.
I actually have to filter the PgmChg to add a Sequencer Stop and a Sequencer Start before/after for immediate program changes. The OT is slave to the almighty “Pattern Chain Behaviour” which can only be set on the OT for PLEN (Pattern Length) or as low as 2/16 (steps), so it requires translation anyway.

Easier solutions are best, and in my case I think I’m opting for controlling Pyramid Sequences via a MIDI Track CC69 from the OT, since I also use the OT XFade and Scene Select data to modulate data in realtime. Plus no additional translations needed.


#6

On the Analog Rytm there is no need to specify the bank. Bank A patterns are Programs 1-16, Bank B patterns are 17-32 and so on. They can be launched by sending just the right Pgm change number. Maybe the same works for the OT.


#7

Thanks for your response.
I’m using the OT, tho: there’s 256 Patterns

My workaround is just to be satisfied with 128 OT Patterns per “song”. :slight_smile:

I could always write a more complex script that will hold the current values of Bank of PgmChg, and when the Pyramid fails to send one of them (because technically it isn’t a change of state, although to the OT it is), the translator would flesh out the whole RAW MIDI Message, but it’s just easier to stick to 128 Patterns.


#8

Hi! I’m a bit late at this thread, sorry.:sweat_smile:
I use the DT as a drum machine in my setup and am experiencing the same problem.
Question is - is there a cc for start/stop? Because this way it can work in a “song” scenario - put a microstep with PC and a stop a step later, with a microstep for start at the beginning of another sequence.
And my second question is what does CC69 do with pyramid? Is that a “sequence change” command?

I’m a bit new at this dawless thing, so sorry if that’s a common knowledge type of a thing. I just prefer asking people after I’ve read the manual a couple of times. :sweat_smile:
Thank you for your time!


#9

Stop/Start are System Common messages, they are not a CC.

Sticking an FC (Stop) and an FA (Start) is a workaround to getting the OT to start a Pattern immediately instead of following the OT’s Pattern Behaviour settings. This is not something that can be done from the Pyramid alone and is done with a Translator. (well, it can be done manually, but you have to be very fast and the whole point of the exercise is to limit the interaction with one machine so that I still have a hand free to do ‘other things’) :wink:

Sticking an FC before and an FA after the PgmChg msg works, btw. I was using it, but still reconfiguring my rig between parallel sequencers for communication between them so it may be a moot point.

When you press [>] (Play) on a sequencer, it sends out the FA MIDI Message to tell other gear to start, if your sequencer is set and/or able to communicate that information. What happens on the receiving end is dependent on the settings on that device (case in point, I can set the OT to not pay attention to Start/Stop).

CC69 is listed on the MIDI Implementation Chart for the Pyramid to accept/control Pyramid Sequencers via MIDI messages.

Reading the manual is important, but at the very least, I’d recommend reviewing/understanding the MIDI Implementation Chart if you want to send control values between gear. Check on the bottom under PyraMiDi Messages and the examples:

I don’t know how ‘common knowledge’ it is. Just part of my personal workflow. :wink:

Note: several other people here with more knowledge than I use DT with Pyramid. If you run into issues controlling the DT from the Pyramid (if that’s your chosen data/work flow), I’m sure a fresh thread on the subject (if one doesn’t already exist) would give you MORE than enough specific application information.


#10

I have a couple of MIDI implementation charts posted on the wall of my studio, but not Pyramid’s. Looks like I somehow skipped that part of its manual.:sweat_smile:
Thank you very much for your detailed response!

Edit
And now, after reading the implementation chart, I see how to solve all (I hope) of my problems with DT and Pyramid.:tada:


#12

@ocolot

Although I’m using an OT vs AR, your original post came through my email.
Shame you deleted it - that’s an awesome workaround, although I haven’t tested it (yet).

It doesn’t apply to my situation as much, since putting the FC/FA on the PgmChg is slightly better for those of us who forget what we did (it kind of overrides Pattern Length stuff on the OT in more of an ‘expected’ way IMO), but it is still an amazing hack.

Repost? Or I can copy/paste the gist of it here?


#13

Yes please repost if you’ve figured something out. My workaround is sending PC changes out the AR, mapping them to cc69 via a translator and pinging them out to the Pyramid. Works fine for instant switching although I’d prefer to just have the one sequencer of course.

Has to be this way round for me until the AR can do instant pgm/pattern changes. Seems to be some debate on the Elektron boards over whether this is a bug or not. But actually it works for me this way round since my AR drums generally dictate the progress of a song, so I’m OK with it being in charge and just relating Pyramid sequences to AR patterns.

Also I actually find the AR’s song mode to be easier to use than Pyramid’s sequence chaining process, so when it comes to finishing a rough arrangement it’s a decent sketch pad.

jim


#14

Hey @JimBrackpool

The gist of the post was about using the Humanise function, set the Humanise % to 100, Humanise- to 100%. I guess that effectively slides events ahead of the tick, but I haven’t tested it.

Sidenote if you didn’t see my workaround above: I find that the less thinking I have to do the better off I am in the long run. Since my ‘expected’ use of the PgmChg being sent to trigger Patterns on my Elektron device is that the Octatrack will change to the new Pattern when the Pyramid changes to the new pattern, to avoid the almighty PtnLen function on the OT I still use a Translator. Effectively this is a better solution for me. It’s similar to what you do, but my translator just listens for PgmChg going to the OT and sticks a [Sequencer Stop] & [Sequencer Start] on either side.

Since setting that up, I have yet to actually think about what I’m doing - since the Pyramid and the OT are now in Pattern Sync. :wink:

Better for me in the long run.


#15

Hey thanks @CreepyPants ,

Yup I saw your workaround, it sounds great, and attempted it with an AR not an OT, mind…But the pattern length/change ‘rules’ are the same on both devices I assume.

Anyway, I got it working sort of, but the timing is pretty sloppy. Like I’m getting flammed kicks on the downbeat when the pattern switches. Sometimes I don’t get a switch at all.

My translator is doing start/stop commands either side of the PGM change, but it is also doing the PGM change too in the middle. Should I be sending that direct to the AR from Pyramid and just leaving the translator to deal with transport? I’m using BOME to delay the PGM change and start messages by 1ms…(Probably a little optimistic with the settings there…) But it’s not clicking. Should all those events happen concurrently?

Any other tips on getting it tight?

Cheers, appreciate your help.

jim


#16

I use a BomeBox and MTPro, although i could use a simpler solution (mIDI solutions event processor, perhaps) since i would rather use my sole BomeBox to translate the OT XFade data to my synths.

I dont even bother with a delay and just look for PgmChg on the OT channel, assign to variable oo, and replace it with “FA oo FC”. MIDI data is sequential and a delay is only needed (i believe) if the receiving unit cannot process the data fast enough. (It happens)

EtA: i tend to use one OT pattern for one Seq on the Pyramid. So i dont switch stuff that often. Generally all Pattern 01s on the Pyramid go together and have a matching OT Pattern. Perhaps my overly simplistic approach has shielded me from any in-depth troubleshooting


#17

Thanks that’s really helpful. I’ll give it a try.
jim