I’m running into an issue when transposing: every time the transpose note is sent, the midi notes seem to get cut off until the next notes from the pattern being transposed come through. Are others experiencing this? Is it a bug? Am I doing something wrong? Is there a work around?
I’ve been having the same problem and would love to know if there are any solutions/workarounds.
It makes Transpose pretty unusable with midi, which is super unfortunate. Seems to work ok using the CV outs though
What you’re describing is the current normal behavior. I wish there were options to make the master transpose more playable:
- Transpose & retrigger currently playing notes
- Transpose next notes but keep sustaining old notes without transpose
- Kill all notes and transpose next notes (this is the current behavior)
I guess this could be easily set in SETTINGS. I’ve proposed this feature on the old forums so I’m pretty sure squarp is aware of the issue.
At the moment all you can do is to know when your next notes trigger and then be very precise with your timing. Bad thing is that it always kills drones. So I’m fully with you. At the moment it’s not as playable as it could be.
yeah, just to chime in… I was super excited for the transpose feature and now I never use it because of hanging notes. Squarp, if you’re out there… please please (pretty please) could you address this issue? It’s so close to being a beautifully functional transposer.
I’m experiencing the same issue, and it looks like fixing this is not very high on the agenda for Squarp, as it’s now 2021… Or could it be that it was actually fixed and I’m missing something?
No, this was never fixed. It has annoyed me since 2016.
This transposition behavior is a bummer for two reasons:
(1) It makes live transposition nearly impossible to time correctly without killing notes
(2) It kills the potential for sequenced transposition through another MIDI sequencer (or a MIDI loopback from other Pyramid tracks)
That leaves you with two options that work:
(a) Sequenced transpositions through the Master Transpose Track — great, I’m happy that this exists, but you only get one track of it, so if you want to transpose more than one track not by the same exact interval at the same exact time, you’re out of luck.
(b) Sequenced transpositions through the same track’s Scale effect’s Transpose parameter — this works, but a track’s “FX automation lane” has to be the same length as your “note lane”. So you end up with results that are basically the same as if you had pre-programmed your transposition into the note lane. Big missed opportunity.
Because of the limitations of (b), I’ve hoped that I could sequence transpositions (or automations of the Scale FX Transpose parameter) with an external sequencer, but the notes get killed.
Also, when you adjust any of the parameters of the Scale FX, the notes also get killed. I don’t understand why Squarp didn’t go with either of these options:
Don’t mean to be so salty here but I am also bummed about how very close the Pyramid is to living up to its potential as a sequencer, and that its continued development was abandoned. Yet it seems to still gain new owners…
Interesting that this thread is still a thing.
I have no idea what is in Squarp’s plans or what their issues are, but Transpose from a Sequencer that is separate from the destination synth is ruled by the whims of MIDI.
MIDI is sequential data and subject to the standards set by the MIDI Manufacturers Association (or something…I think). So, there is only so much that can be done.
Regarding Drones: Once a Note On Event is sent from the Pyramid, you want the subsequent Note Off Event to coincide with the correct MIDI Note #. So…let’s say your drone note is C1 and Pyramid faithfully sends out a Note On Event for C1. And then you Transpose. What do you want the Pyramid to do? There is no MIDI message for “Hey, change that Note”. And if internally the Pyramid decided to change it’s understanding of that note to be D1, and once the drone is over sends a Note Off Event for D1 then you have a stuck note. So…wut?
What do you propose the Pyramid sends out in this situation, keeping your answers specifically to what is available to us via MIDI Messages?
I’d say cut off Notes is probably the best way to handle things.
Remember the Pyramid is NOT your synth - the synth only understands the Pyramid when it speaks the common dialect of MIDI, and with a few CC’s perhaps some colloquialisms.
Another question is: Is there a MIDI message that your synth (and truly we’d need to think “most synths”) understands as ‘change this note for that one’? That’s usually handled by a Pitch Bend message.
So, I’d say:
- Do you want Transpose? Transpose is not a standard MIDI message. The Pyramid does what it can with the tools provided.
- Would you rather a Pitch Bend? Let’s say you set your synth to Pitch Bend +/- 12 semitiones. Then just create a Track that only sends Pitch bend information from one place to the other and make that Track Trig Run Mode. Then just activate that Track. Yes, you have to do that for every melodic Track you want to change, but you can workaround with an Event Processor.
Again: What MIDI Messages are you suggesting the Pyramid send out to do what you are expecting? Summary of MIDI Messages can be found here.
Now, how’s that for salty?
The Pyramid is still one of the most significant pieces of hardware out there, but I think many of the limitations are inherent in MIDI. I’d still love to carry on the convo about what MIDI messages might happen because I use Event Processing extensively and it’s be nice to implement my own Transpose (well, I kinda do that with some synths, but I use the Pyramid sending a CC which my devices grab and then force a SysEx message to the synths, but i’ve never tested it doing the thing y’all wanting to do)
@maximee laid out the options here really helpfully:
That option #2 is the only way you could tell a sequencer to “transpose” its sequence without changing the series and timing of Note On and Note Off events that has been programmed into that sequence. It can be done with “sample and hold” logic: before the sequencer create a new Note On event according to the steps programmed into it, it evaluates
(1) the pitch programmed into the sequence
(2) the last state—at the moment before that Note On is programmed to send— of (a) all FX that could modify pitch + (b) the current master transposition state.
And then, and only then, does it emit a Note On event with the pitch that’s determined by the combination of (1) and (2). Any changes to (2a) or (2b) that happen before that moment are ignored; only the last state of those parameters is “sampled” at the moment before the Note On is programmed to happen, and is then held until just before the next Note On is programmed to happen.
This would be a nice option for transposition, as it’s much more forgiving with timing—if you want to transpose the sequence before step N without changing N’s timing or duration, you only have to time your key press (or external sequencer) to arrive just before the sequencer passes step N. But without this kind of entirely possible logic (that must be employed on most synths that contain their own sequencers or arpeggiators + keyboards, as I’ve never experienced what Pyramid does with transposition & timing before), you can’t transpose the sequence without fudging a note’s timing.
Hope that’s clearer now!
Not trying to hate on the Pyramid; it’s a brilliant sequencer that I’ve spread a ton of good word about since buying from one of the first two batches in 2016. I would just love to see a few rough edges polished that hold it back from some major step changes in power.
That makes sense.
Im so fixated on the drone thing.