I have encountered an odd problem where pyramid will not send some notes and CC messages stored on the first step of a sequence. This seems to happen in all SEQ modes (perform, play, and loop).
Example: I have a sequence chain featuring a synth track. I am using CC #71 and #24 to control the tone of the synth (cutoff and env amount). I set each CC to send on the first step of the pattern, setting the tone for that pattern. Then I set up pattern 2 in a similar way, with different CC values also stored on the first step of the pattern.
In SEQ mode, I chain the 2 sequences together and press play. When switching between the 2 sequences, the first step of the next sequence is not played and the synth tone does not change according to my CC messages.
Caveat: if I move my CC messages to the 2nd step (even zoomed in all the way), the messages are received by the synth per usual, but one step late.
I have encountered this problem with CC messages and notes as well. Sometimes a bass drum note on step one will not play when initially pressing play, but will play once the track has looped. I have ensured the notes are not offset slightly behind the beat.
What am I doing wrong here? Am I perhaps overloading the MIDI out with too many messages? I have a few synths chained, but the drum machine and synth in question are both first in the chain from MIDI out A and B. But I am nowhere close to maxing-out the pyramid’s capacity of 64 tracks or channels. Just sending notes and a few CCs on the first step of a sequence.
I spent some time last night troubleshooting this. I noticed that the bass drum kick would come through on step 1 once I muted a few tracks - so it seems like you CAN overload the MIDI processor pretty easily, or else this is a limitation of the synths I am using (Roland TR8, Sh-01a, MX-1). Anyone else notice this?
I had quite a few CCs being sent on step 1, which seemed to cause intermittent delays and dropped notes/messages. I should note that Pyramid automatically saves some CC states on the 1st step of the track/pattern when they are initially set. So there were a few CCs that I didn’t realize were being sent.
The tracks from my project were recorded using LIVE mode with quantizer added. This seems to add a complication. When quantizer is added to a track, it will non-destructively align the notes to the grid, which means the notes really exist in the original position on the grid
I had some notes on my track that were played slightly early on step 1, meaning that they were in front of step 1 in my pattern and quantized to play on step 1. When I switch to that pattern on the next bar, the early notes are not played, even with quantize on. I think this is because the playhead must pass through the early notes in order to quantize them. However that doesn’t seem right because late notes are predicted and played early through the quantizer. Seems like the same should apply to early notes.
Ultimately I used STEP mode to re-input all my notes which I previously recorded with LIVE mode so that quantizer was not needed. And I deleted all my CC messages. Now the sequences play without dropping notes, but I will need to start adding automation back one at a time to see what causes it to start dropping notes.
Maybe it was too much CC? Maybe it was the effects processor? Maybe it was both? I guess this means i need to do a lot more planning for tracks instead of just recording stuff on the fly/adding effects and expecting everything to just work.
Just today I started experimenting with re-recording tracks (MIDI output to MIDI input) to make the MIDI effects “permanent”. So far it’s working perfectly as a way to trim down the effects, but I haven’t tried it with tracks that contain lots of cc automation. Rather than re-input your material in step mode, next time you might try re-recording.
If you still have the original tracks that caused the issue, try playing them into a midi monitor on your computer (assuming you have some sort of midi input device) and see if the dropped notes were actually transmitted or not. Then you’ll know if the Pyramid or your external synths are at fault.
You might even be able to just loop the out to the in and turn on the midi monitor in the pyramid to do this, if you can’t use your computer.
The midi output monitor won’t tell you if a note was really transmitted. You need to look at the receiving end for that.
On your other point - DIN midi doesn’t have a max rate, it has a fixed rate. It transmits one thing at a time, at the fixed rate. If there is more than one thing to transmit at a given time (like at the start of the pattern), some events will be delayed. It’s possible for the transmitting device to fail to transmit something due to buffer limitations, but generally you just get stuff occurring milliseconds later than it should.
When recording live, if the first note occurs a bit early, it can end up as the last note of the track so it wont play when the track starts but it will play when the track loops. See Note offset +/- 50% - is it ever going to happen?, this is quite a common problem.
I have all kinds of data on all sorts of tracks at 1.1.0 and do not have midi notes dropping out.
I’ve got a Pyramid MK1 and haven’t seen this on any version of the OS.
However, I do have an evolving program change issue. Originally the program changes would upset the notes, and I talked it over with @squarpadmin via email and in an update the notes stopped getting cut out, but the program changes started to take a cycle to kick in.
I walked this over more with Squarp via email and eventually the problem seemed to go away. I figured they worked it out.
In the most recent rounds of changes (from 2.3 - the current beta) the program change delay/note dropping out issues have returned.
I wonder if you have program changes on 1.1.0 in your patterns/tracks?
If you do, try removing them as an experiment and see if that brings your notes back on the 1?
This could be a data hierarchy issue which can be solved, and has been solved before, but is easily overlooked because not all gear responds to program changes the same way (ex: The Access Virus just can’t do it on the 1, the Roland Boutiques glitch on the 1, and the OB-6 works like a charm no matter when you sent it.)
Thanks, I’ll investigate your suggestion and report back, I suspect something else is going on, because I’m usually starting from a blank slate. Either way, I’ll look into it
We did not notice any PROGRAM CHANGE and NOTE issues with the current beta. Do you have a procedure to reproduce this bug, if it still occurs with your setup?
You can use MIDI monitor (MacOS) or MIDIOX (Windows) to monitor the data sent by Pyramid.
I just made some tests. When no PC are set, and you press play, Pyramid send in this order:
START
CLOCK
NOTE ON of the step 1
(these midi messages are following each other very very closely)
When a PC is set, and you press play, Pyramid send in this order:
START
PROGRAM CHANGE
CLOCK
NOTE ON of the step 1
@Sunshine@Ptbarnum@pmatilai Maybe it comes from your midi synth. Can you please precisely describe your problem, so I can investigate it further?
When you say it might come from our midi synth, what settings should we look for as the cause? It’s a frustrating bug hard to tell what is causing it
Gotcha, I’m assuming it’s a pyramid problem, because I’ve rotated through various synths, and the problem persists. I’d be happy to email you a project that demonstrates the problem👍
@squarpadmin, the thing I was talking about is pretty well covered in topic I linked earlier. It’s not specific to the beta, I know I’ve seen the phenomen on v2.30 but don’t have a reproducer at hand and couldn’t create one yesterday when I briefly tried to.
That said, there are clearly several different issues being talked about in this topic. And while checking the sounds of a newly acquired expansion board for my JV-1080 today, I realized that on some patches have a very noticeable loading time, probably closer to half a second worst case. The behavior is such that if you select a new patch and then quickly hit a note, the note will start playing after the load has completed but a 1/8 or 1/4 note could easily get lost in there. And that wouldn’t happen on the next loop of course because the patch is already loaded. However I don’t remember seeing missed notes with step-entered data so … I dunno. I’ll keep an eye on it and investigate closer if/when it happens next time.
