Squarp Instruments Hapax Polychronic Performance Sequencer

[MatthewAllen]

given that there are 16 pads across

you can zoom in to super small section, so its not really 1/16th notes, you could get into to like 192nd notes (I think it may be even further)

In my specific example I trigger the megacommand that then quantizes when it responds to Program Change and set that quantize length to 4 beats, so on the Hapax I send the PC 4 Beats early.

Does that extrapolate (across the pads) if you make your pattern longer than 4 bars?

Regardless of length of pattern you can zoom in and out for greater or finer control.

[mssrcolby]

Any one done any direct comparisons to the Deluge?

[Uija]

The thing is, that switching pattern on Step1 of a Pattern is too late, you need to send the Change before the next pattern starts on Elektron devices. So either you need to micro step them before the 1 (not all sequencers are able to) or just send the Change on the last step of the pattern before.
While it might be an issue with Elektron devices, that they have nothing to change even if it is too late, it is a valid decision, as the change that is sent on the first step of a pattern in an synced environment cannot arrive before the first step is played due to physics

[thetechnobear]

Yeah, there’s some subtle corner cases on this.

Obviously , the main reason it ‘flawlessly’ works between Elektron devices is, as a single brand they explicitly test it, and of course know ( internally) how much lead time they require.

The thing is different synths, need more or less time to switch presets ( some are almost instant, some are pretty slow)

Then we have to look at what’s possible.

If the transport is stopped, then the sequencer can only send ‘early’ if it is the master, if it’s slaves to something else … by the time it’s told to start - it’s too late.

However, I guess the main use case is changing patterns during performance….
Here we have to bare in mind , the time marches on regardless.

So the if you have no sync, so immediate switching … the sequencer cannot send early. It’s too late already.

If you have sync on, eg 1 bar then IF you don’t switch patterns too close to that point … then it should work.
Eg let’s say ( for illustrative purposes only , I know it’s much less! ) it takes 1 second for a device to change patterns … then if you switch patterns 1/2 second , the sequencer cannot send really enough … since it’s going to sync on the bar still.

In practice , If you approach Squarp, I suspect they could do something, within these constraints ( basically it’ll get sent early IF pattern change gets ‘queued’)

I guess that early time will also have to be per track, since as above , it could be very different depending on synth/sequencer your targeting.

Definitely worth raising a feature request for and talking through with them , as implications go beyond Elektron devices.

as an aside, and not entirely related , but I wonder if Squarp start supporting track latency ( offsets), then this might be a good opportunity to look at this to.

[Dymaxion]

Surely they could add an attribute to pattern change events that’s a time offset from the position of the event to solve this problem? Assuming you’re using a quantized pattern start and the sequencer is told to start the pattern at least offset milliseconds before the actual pattern start, it should be fine.

[thetechnobear]

‘Should be’ is where bugs creep in!

Who says a ‘few milliseconds’ is enough for all synths … you don’t code just for Elektron ( unless you are Elektron)

Then as above, you can’t just schedule the event in advance, in all cases since you may already be past the time…. At which point you have to send immediately regardless … as it’s all you can do.

This is why developers need to think about all the corner cases …whereas users have the luxury of just thinking about their requirements.

Trivializing dev changes is a bit like saying why do musicians need more than one kick sound , they all sound the same

[Dymaxion]

I’m not trivializing it. I didn’t say a few ms, I said an offset in ms. Could be a few thousand, it’s the same problem. Yes, you cannot schedule an event to be sent before the sequencer knows the pattern will be started, obviously — hence my point about quantized starts. If the sequencer is following an external clock and the user tells it to start a pattern on the next bar, it can scan the pattern and check for PC events with negative offsets and send those before the actual pattern starts. In that situation, it won’t handle synths that need more than a beat or two to respond to a PC event, but that’s not something an external sequencer can fix.

[CatLitterForBrains]

@thetechnobear thanks for your comments on this topic.

Have you been able to use/test the Hapax with an Elektron device to confirm if the timing phenomenon I described with the Pyramid also exists when sequencing with the Hapax?

If yes, are you able to send a PC message (via automation) on the Hapax early enough in time to keep both devices synced when you change patterns?

[thetechnobear]

the only Elekton , I have is the Octatrack…

and I really don’t sequence much with it (with the Hapax) , as I use it more for recording audio, and then mangling, more with scenes, than parameters locks… a hands-on instrument.
so I pretty much just need it in sync - so that one shot record/playback is sync’d.

I don’t really use it much for static samples, were I guess you would then use patterns.
but even there… for my limited use, Id probably just trig the samples from the Hapax, and use its patterns.

… but I do understand why YOU need it,
if your doing a lot of Elektron programming, then of course, you want to do pattern programming on the Elektron, so you can use parameter lots etc.

tl;dr… Id need to check to see if the Octatrack works the same as the newer Elektrons (Digi-)…
as, I thought it had some weird oddities in this area, that meant it wasn’t as simple as sending a PC to switch patterns…

so not sure, its worth testing with the Octatack?
anyone? is it as simple as a PC?

if it is, I’ll give it a go…
(I just don’t really wanna spend hours banging my head against a wall for something I’ll never use )

EDIT: I’ll go check the pyramid/octatrack thread on Squarp… see if I can find out what the oddities were… I half remember it being a two step processing, involving stop/start of sequencer.

[thetechnobear]

ok, here’s the Octatrack shenanigans…

Sending Bank Change and Program Change

seems main issues are : (reading post)

a) Pyramid won’t send a PC , if its the same as the last one sent.
this is a problem, since it does not take into account the BANK (MSB) might have changed.
… I’d need to verify if this is the same with Hapax.
only an issue if you need more than 128 patterns!

b) Octatrack won’t change immediately
it relies on its “Pattern Chain Behaviour” , which can only be set as low as 2/16
the way they have got around this, is to inject a stop/start sequencer midi message.
(as this will instantly change pattern when its restarted)

---

(b) is kind of an interesting one…
unfortunately, I suspect its behaviour is not the same on your Digitakt? so Im not sure if its worth me testing … apples n’ oranges? though it be good to confirm this.

also reading this ‘immediate change’, I think is partly fighting against the wind… (*)
Im assuming the OT designers thoughts were…
you send the PC very early, then you let the Octatrack handle the synchronisation.

whats interesting here is… is this the way the Elekton devices ‘sync flawlessly’ between each other?
they simply let each box handle the synchronisation… and just make sure the PC is sent nice and early?

---

the bad news in this particular case (quite possibly OT specific, as I need to try a Digi- to know)

• adding an extra midi message in flight (stop/start sequencer) for instant pattern chain - is not a reasonable thing to expect a sequencer to do… way to OT specific. so really, id use a midi processor as the posters on the squarp forum do.
• feels like if you are willing to let the OT sync its pattern change (which feels right for me), then the PC would need to be sent ‘really early’ … not just a few milliseconds.

I’d like to play with this a little see how it really pans out if used in ‘anger’ ,
however, Im not sure it really sheds any light on to the Digi- situation , as this might have all changed.
Im mean the OT is one of the oldest of Elektron’s beasts.

---

(*) to be clearer the original poster has really good reasons for wanting this instant pattern changing, to do with which machine is in control… so would prefer the OT setup doesnt ‘encoder’ this sync info.
so, definitely its comes down to individual use-cases.

[CarlosUnch]

@CatLitterForBrains

that led me to believe the issue is with Elektron devices

Sure thing. I’m not versed on the matter myself, I just know that in order to make timely program changes on OXI, it’s actually sent at the very end of the last step of the previous pattern slot. AFAIK that fixed the issue with Elektron devices.

[thetechnobear]

@CatLitterForBrains
ok, so I tried with the OT…

so, ignoring the OT oddities… yes, it pretty much has the same same issue, as I expect your seeing on the Digi-
basically the OT, will schedule its pattern changes, by using it own synchronisation…

this means, if it receives a PC, when it already believes its already on step 1… then indeed, it will wait for the pattern change period to switch…

if your programming patterns that always follow each other thats not a problem, if you use PLEN, then put an automation step with PC on any of the last few steps of sequence, it’ll work nicely.

BUT thats not a great solution, since it assume P1->P2->P3->P4 … what if you want to go straight from P1 to P3… , the automated step on P1, would make OT go to P2.
so definitely see the issue…

I’ll have a chat with Squarp, and see what there thoughts are on it.

[MatthewAllen]

for now you can manually do it by using a PC automation lane, but that is a bit more work to track and update.

[thetechnobear]

Yea, but as I said above … that fixes the order patterns are launched.

We’ll see, I’ve raised it

Honestly though, as a dev, it smells like the kind of issue that’s not going to be a fun/neat fix … and one you know that’s got a high chance to bite you later.
But I don’t know their code base so perhaps we’ll be pleasantly surprised

[josker]

At least the Cirklon dev had to add a separate ”pre-send pgm change” mode to the Cirklon for exactly this reason. He worked out the amount of time Elektrons need to react.

[thetechnobear]

On the octatrack ( not sure about others) you don’t need exact time at all… since the sync is done on the octatrack, it just needs to be before the start of the pattern.
Also there’s not a huge advantage doing it close to pattern end , since the octatrack allows you to ‘reschedule’ the pattern change anyway.
so that would allow hapax, to say it’s going to change to p4 then say oh no, I mean p5

The only limitation is , if you change did this change very last minute… then it’s likely be too late … but that is just learning the limitations of your instruments.

As I say , not sure if other Elektrons are the same , do they have the same pattern change behavior ( definable by user) ?

All that said, I think I’d use a small time offset … just because relying on the Elektron/octatrack to do the sync - is very Elektron specific … eg it’s not much use for synths, that also need this behavior

[josker]

Yeah, not exact, but if memory serves, you need to send it ~4 steps before the actual change to get the Elektrons to hop on board

[Uija]

Nope, you can do it even after the last Step. I built an external Songmode based on NeoTrellis M4 around 2 years ago, and I sent the change around 1/16th before the next pattern started. I think it could have done later, but that was my grid the song mode worked on.
Worked perfectly with DT, DN, M:C and M:S.

[josker]

Huh, interesting! My experience is with the (mk1) big boxes - might be that something was different? Or not, and I just got the wrong idea, testing stuff out by hand at home

[Uija]

I just rechecked the code, that I don’t communicate wrong facts, but it was indeed 1/16th before the pattern ends.