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


#18

Greetings-
New to Pyramid. I have done my best to RTFM and read all the forum threads pertaining to the issue but my efforts have still not succeeded. If I have missed something obvious please forgive me.

I’m having an issue sending program changes from the Pyramid to my Elektron Model: Samples that sounds fairly similar to other stuff I am reading here. I have tried numerous different ways including using a trig on a pattern of a dedicated track and using the track mode setup screen and altering that for each corresponding pattern.

Using either of these methods seem to work fine if I manually select the pattern myself on the pyramid, but when I try to sequence 2 patterns (in Pyramid seq mode) and make the Elektron change back and forth, it seems to only work one time or not at all (on the Elektron) while the sequences continue to play back and forth on the Pyramid just fine, and the numbers on the pyramid act like they are changing.

This all sounds like earlier posts which leads me to believe that this particular issue is still an issue, but also possibly not considered something that needs “fixing” since the latest firmware has a message attached saying “all known issues fixed”. Is it possible Squarp doesn’t know about this at all? Or is it more likely that this is the Elektron being finicky about the messages?

I am just thinking out loud here, not really complaining. If there’s a solution or workaround that doesn’t involve a computer (not a good option for me) then I am all ears.
Thanks!


#19

Greetings.
Mine was the OP.
It’s only an issue in that it’s both devices operating within normal parameters, except those parameters did not yield a preferred result. heh (Sorry, just re-watched ST:Discovery so my english is probably off)

You state you are having an issue but I’m unsure what the issue is:
Does the Pyramid not send a MIDI PgmChg msg?

  • Verify that Pyramid settings are correct
  • Test the PgmChg msg via MIDIOx or other suitable MIDI monitor system/device (Has anyone built a Raspberry Pi MIDI monitor or something yet? hrmmm)

Or is the issue that your Elektron device is not processing the information as expected?

  • I’m not familiar with the Elektron:Samples, but I know that the OT has a setting for PLEN, which basically (functionally?) goes something like: “once the device receives a PgmChg, how long until I change the Pattern”. Said PLEN can never be 0 for an immediate change. I’ve documented above how I use a MIDI Event Translator (MTPro running on a BomeBox) to stick a Sequencer Stop and Sequencer Start on either side of that.
  • Verify with your device that it is operating as expected. (perhaps someone on the board who is familiar with this device might chime in)
  • Test with other devices sending PgmChg: is it different when using the Pyramid than any other device

Are all hardware connections and cables solid and in working order?

  • Yeah, this is a thing. Start with swapping out cables. My overly a-r suggestion is to always buy the best cables possible. Nothing like destroying a beautiful performance from $10k in synths with a $20 buggy cable

This thread was dedicated to a situation that did not require ‘fixing’ via OS updates on the Pyramid or my Elektron devices; just a matter of gear-being-gear and manufacturers not imagining someone would want to control their device with another device. LOL (/jk)


#20

Indeed. I want to control my Elektron Model Samples from the Pyramid and am having the same issue. What is not clear to me is if you ever solved your issue within the hardware universe or were you forced to use the computer to achieve your results. I am a live improvisational performer and my studio rig is the same as my live rig with no computer (regularly) involved.

The only thing on your long and very helpful list (thanks for taking the time) I haven’t done/verified is to plug in to the computer and monitor the MIDI which I will do today. I suspect I will find the same thing you did, since the behaviors are practically identical.

Like I said in my post, the Program changes occur flawlessly when I select them manually by pressing “Step” and choosing the corresponding pattern. The only issue I am having is that the prog changes don’t happen in sequence mode when playing sequences.

  1. Does anyone have this working?

  2. Mind sharing how?

Thanks for the reply @CreepyPants, I appreciate it.
PS your English is great.


#21

I shouldn’t make that joke on an international board.
English is my first language.
I just really suck at communication. :wink:

Apologies - I assumed it was evident in the thread that I solved the situation. There are multiple options depending on the way your brain works (some people need a conceptual approach and fill in the details on their own, some people need a step-by-step).

The problem is that once the Pyramid sends the PgmChg msg, the OT would wait until the value of the PLEN allowed the Pattern to change. A basic workaround is to trigger the PgmChg ahead of the point you want the Elektron Pattern to change, but that’s cumbersome and does not work for my process.

Basically what I’m doing is interrupting the data flow from the Pyramid to the OT and making a minor modification to the MIDI data to insert commands to STOP the Elektron Sequencer before the PgmChg msg, and then START the Sequencer after the PgmChg msg. All of this occurs in a sequence of Bytes, so it is (effectively) instant.

Honestly once I set it up, I’ve forgotten about it (mostly) because my rig now operates as I think should be intended.

it does require a computer to set this up in most scenarios I’m aware of, but only requres the computer to move the correct stuff to a hardware device and then put the computer away.

I personally use a BomeBox, which is a MIDI device that does LOTS of things (rules/logic, filtering, routing, etc). Making a minor change to the MIDI data stream is such a small thing for such a powerful device, but I use my BomeBox for other things (routing, USB MIDI -> DIN MIDI, complex translations and logic (rules) for a button controller to sort of “macro” Pyramid functions, etc). To use a BomeBox in this manner, you also need MIDI Translator Pro, which allows you to create scripts that handle the data.
BomeBox is ~$200 US; MTPro is ~$50 US (I forget the exact prices these days and I’ve been using both for years - pre-release user of the Box)

I believe you can achieve the same thing with an iConnectivity device (which one I’m unsure) and perhaps a MIDI Solutions Translator. I use neither so I don’t know how they’d be used in this situation. If you decide to go one of those routes and no one can step you through and you need assistance, I’d be happy to help figure it out, but it’s not my forte.

If you’re a detail person, what I’m doing is:
Incoming - Any PgmChg from the Pyramid is in the format C8 xx
where C indicates it’s a PgmChg message, 8 indicates it’s on Channel 9 (channels start at 0 on the machine side of things), and xx=which PgmChg value I’m sending

Then instead of just sending that through, the BomeBox snags that command and changes it to:
FC C8 xx FA
Where “FC” is the MIDI Sequencer Stop message and “FA” is the Sequencer Start message.

It may be confusing, and if you want more info you can direct msg me - you can probably tell I like to type/talk - blahblahblahblahblah. :slight_smile:

Some of this stuff is basic MIDI, some of it a bit more complex.
I have no idea what your familiarity with MIDI is, nor how far down the rabbit hole you want to go.

Note: after typing all of this I think I wasn’t awake and thought it was a different thread. My original problem was selecting Patterns on the OT because the Bank Change wasn’t getting sent because Pyramid doesn’t send a Bank Change command if the value does not change, but the OT needed the command irrespective of a lack of a value change. I got it confused with a tangent on the Sequencer Start/Stop, but I think that’s what you’re looking for? Blah