Do you control the Pyramid via PyraMIDI?

I’m running into a ‘thing’ and was wondering if anyone else can duplicate it.

Not going to type the steps to dupe, because: reasons.
Let me know if you use PyraMIDI and if you’re up to to testing a thing and I’ll post you steps.

I use PyraMIDI extensively. Most of my workflow depends on it.

In fact i would love to have some additional PyraMIDI-functionality. If i could pick just one it would be to trigger HARD REC via midi CC. Its only REC for now (CC66). I am getting around this limitation by using the Pedal Input wich CAN be set to HARD REC. But this funtionality comes with a few bugs of its own…

If it’s not too difficult i can give it a shot!

Hey, thank you for responding.

I agree that Hard Rec would be an excellent addition to PyraMIDI functions. I also would have liked to be able to select Pattern via MIDI…I had suggested that a Note On msg could select the Track and the Velocity byte could select the Pattern. But I’m still tickled with what we can do!

I’m wondering if you can duplicate this. I’m asking because my brain doesn’t work terribly well anymore and I don’t know if I’m trying to troubleshoot correctly.

Triggering Tracks with PyraMIDI, specifically Trig Mode Tracks.

CC01-CC64 to Mute/Unmute Tracks: 0=Mute; 1-126=Unmute; 127=Toggle
In my system, I send a value of “1” to Unmute and I generally don’t use Toggle. (Note: I realise I didn’t test this, but I can’t use 1 sometimes and 127 others because of my event proc code)

I think I’m experiencing a confusion or an error in triggering Trig Mode Tracks via CC in that if a Trig Mode Track is allowed to play out (finish/complete/play everything and then shut down on its own/etc), it cannot be restarted by sending a value of 01, but a value of 00 (which should Mute) does the opposite and UNMutes the Track. Subsequent restarts of the Track require the value to be 00 rather than 01. However, if you interrupt the output of the Track by Muting it with a value of 00, then the Track is restarted with a value of 01 (as expected).

I’m wondering if you can try to dupe this for me and/or if you have further insight I’m missing, I’d love to hear your thoughts/counsel/etc.

To duplicate:

  • Set Track 01 set to Trig Mode.
  • PyraMIDI Channel 16 in my rig
  • Track Mute MIDI Message per MIDI Implementation Chart should be 0xBF0100 (or better yet: 0xBc0101 where c=MIDI Channel)
  • Track Unmute MIDI Message should be 0xBF0101

While the Sequencer is stopped, sending 0xBF0101 will Unmute Track01 and sending 0xBF0100 will Mute the Track as expected.

Now Press Play

  • Send 0xBF0101 to Unmute Track 01 and let it play through; works as expected the first time.

  • Send 0xBF0101 again, and the Track does not Unmute

  • However, while the Pyramid is still playing and has not been stopped or paused, send 0xBF0100 (supposedly to Mute the Track per MIDI Implementation Chart) and the Track will Unmute and play though

  • If you wait for the Track to play though and Mute itself (Pad goes to unlit), 0xBF0100 will still Unmute the Track

  • If while the Track is playing (ie Pad is lit) irrespective of whether I sent value 00 or 01 to Unmute it, I use 0xBF0100 to Mute the Track (again: while the Track is playing), then 0xBF0101 will work again on the next time I attempt to Unmute the Track

I would appreciate it if you could try to duplicate this and let me know what you find and/or what your thoughts are. I think I’m probably doing something wrong or having the wrong expectation due to addled grey matter, perhaps.

Note: I just realised that another workaround would be to just put a tag in a Trig Track that would force a loopback to Mute the Track (via event proc), and just pad the Trig Track with extra blank space (so, a 4 bar Trig’d Track would have 4 bars of Events, then the ‘tag’, then say another bar of nothing).

Would you have any other suggestions for a workaround?

I use a BomeBox to proc data in and out of the Pyramid, and I ‘bury’ msgs in the MIDI data to trigger Event Processor events (such as, I use Note #'s 1,2, &3 (since I never seem to actulally play those) to trigger Event Proc events based on the Velocity value) so I have quite a bit of flexibility with sending control info in and out. Plus I have trigger Track Mutes with an external controller, and that data also passes throught the BomeBox and I currently track which Tracks are playing or Muted, so that data is actually available outside of the Pyramid.

Thank you for taking a moment to consider this

wait, CC70 controls Hard Rec, no?
Sorry, I don’t use it, but that’s on the MIDI Implementation Chart.


oh! i was not aware! i had been looking at the v3 Midi implementation Chart because i had downloaded it. It actually never crossed my mind to check if the chart got updated… So they added this! Thats huge for me. I need some time to process this news. It’s really great. I am dizzy now! I am also using a bomebox to “talk” to my pyramid.

Concerning your question… i actually never trigger tracks to play once. So this feature i am not accustomed to. But i will check it out for inspiration. I would think that an error like the one you describe can exist. I for instance have found a bug that i can reproduce that is conditional. So it only happens if i have just come back from another selected track.

I will read through your post again tomorrow to clearly understand and will give it a try in the studio. Could be a couple of days though…

1 Like

Thanks for checking into this. I appreciate it.
I usually don’t use Trig Mode, but I’m attempting to do a sort of conditional phrasing that fits with my already overloaded crosstalk between the Pyramid and the BomeBox. (Chance for a whole phrase, or maybe even just additional passing tones for an existing phrase, rather than just a chance for a singular note event)

So i can confirm/duplicate your findings!

I played around with a 2 bar track set to trigger-mode and sent it CC values of 0,1 and 127 on the the Pyramidi Channel using the CC# of the track being controlled.

If the track has run through and muted itself a CC value of “1” will not restart the track but CC value “0” will (value “0” should actually do nothing as the track is muted already). Value “127” (toggle) will indeed work as expected!

If i change to one of the other track play modes the CCs work as expected!

If think this is a bug. Have you already reported it?


Thank you for testing this and letting me know!
Appreciate it.

I would say this is not what I expect from the documentation, and I have reported it. Since the microsample of Pyramid users that also frequent the Forum who use PyraMIDI to control the Pyramid is roughly…2, then I doubt it’s a high priority.

Now to ponder a workaround…!

There was a reason why you can’t use toggle? Cause that would be my workaround.

I don’t know if this helps but i am using two connection between BomeBox and Pyramid. USB and Din Midi. That way i have more possibilities for alternative routes. I also use a wireless Numpad/Keypad for additional triggers (keystrokes/shortcuts).

There must be more people using Pyramidi. It opens so many ways to operate the Pyramide without standing right by it.

I have also reported our thread to support!

1 Like

Well, I need to think about that, honestly.
I typed a bunch of stuff then edited it out; suffice to say: I"m really “out there” with how I interface with Bome & Pyramid. It would be a painful waste of bandwidth for me to share all of it here.

Thank you for also reporting it.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.