Octatrack integration with Pyramid and Hermod

Im just about to get an Octatrack and have been thinking how best to integrate it within the Squarp Ecosystem.

I know there are quite a few great posts on here about this integration, which Ive enjoyed reading (thanks to all for sharing) … so this is kind of a summary of how I think others are suggesting to setup.
so I wondered if the following is reasonable, or if Ive misunderstood something.

general idea:

  • pyramid main sequencer (for both other instruments and eurorack)
  • hermod midi/cv interface, and clocking and ‘midi effects’ etc
  • octatrack looping/sampling/audio effects … possibly percussion samples


  • Octatrack <- DIN IN/ MIDI A- (*) - > Pyramid
  • Pyramid <- USB midi -> Hermod
  • Pyramid MIDI B -> midihub -> other synths
  • Pyramid clock master … (turbo midi to octatrack?)
  • audio : octatrack to/from to eurorack
  • audio : eurorack final mix -> output

I suspect I’ll use flex machines with neighbour to do the loop recording/layering side.
(I’ll test pickup too… so I have that as an option)
I plan to use resampling quite a bit, for layering.

I also plan to record quite a few sample on octatrack from modular for ‘one hits’, esp. for creating percussion library.

my understanding from ‘issues’ reported on forum:

trig slices : trying to trig slices via midi, can only be done with delay (unacceptable),
so my plan is for Octatrack to have its own sequencing… Id guess I might sequence it from pyramid for one shots (but seems unlikely)

so the setup is going to be multiple sequencers that are sync’d, a bit of a pity to not have centralised sequencing (on pyramid) , but on the other hand this way allows me to leverage octatrack sequencing features.

this leads to usage of patterns…
patterns: I need to review posts, Ive seen some issues with pattern changes - but I think this mainly seems to be around changing (midi) banks? if so I’ll try to stick to simple program changes.

(*) if I have issues surrounding midi, Ive an option to router midi via midihub, which can do midi processing.

Im still testing clock sync from pyramid to hermod, using both midi and cv,
pyramid cv for clock seems tighter than usb midi, but hermod seems to introduce a small delay if you use with a CV clock input - compared to clock coming from usb midi.

Ive yet to test if the same is true for clock input into pyramid.
if this is tighter, then I could move hermod to become the clock master.
(but that feels a bit strange if most sequences are coming from pyramid)

that said, I believe the clocking I already have seen feels acceptable, so its more refinement than an ‘issue’.

does above seem reasonable?
any suggestions? tips?

Its a good combo if you try OT and PYRAMID together.
I am using OT’s internal sequencer for its audio tracks and its parameter locks and I control mutes, scenes, the crossfader and pattern change, from PYRAMID using the auto channel defined in OT. For the mutes/solos i use bome midi translator to have them assigned to specific CCs on the same channel(auto channel). This way you can have a proper song mode that is in my opinion is weak and slow on board OT(arranger mode).
I have OT connected thru midi A of Pyramid (not using turbo mode) and I am utilising 9 channels. Connections are realised thru an iconnectmidi4+ with complex routings(attached image). Pyramid is master sending clock and start stop messages to OT.
With regard to the pattern change in OT yes there is a problem which can in a way be remedied if you send from PYRAMID along with a program change a sequencer restart message(note No33 if I remember correctly) which causes OT to restart playback so in effect to have an instant pattern change.
So you can have one pyramid track controlling the OT parameters I mentioned before which means 32 patterns. I use more than one pyramid track which usually correspond to different songs.
No euro rack or hermod in my equation!
My only problem in this setup is when i load a new song in pyramid and although I Have selected the options “SYNC STOP” and “SYNC LOAD” to the on value, OT stops playing because it maybe senses a gap in the incoming clock. This happens only with OT. Other sequencers in the midi chain keep their sequencers running.


1 Like

I have a somewhat convoluted mutual hug of midi routing between my octatrack and pyramid that I enjoy.

a midi merge box receives (1) midi clock and transport from USAMO, (2) manual events from a keyboard, and (3) all octatrack midi data except clock and transport. the Pyramid receives all this data from the merge box and also sends midi (clock, transport, and anything else I want to sequence on the octatrack from the Pyramid*) to the octatrack out of midi output B. midi output A sends a different stream of midi data to other synths.

what I like about allowing my pyramid to receive midi data (except clock, since the USAMO is much better than the octatrack on this matter) from the octatrack is that I can use OT MIDI LFOs to modulate pyramid FX (much nicer this way than step sequencing FX parameters on the Pyramid, or doing a midi or CV loopback on the Pyramid), map the OT’s crossfader (which does send out a CC message) to produce changes in the Pyramid or some different CC message, and record into the pyramid loops of MIDI data that I really enjoy generating on the octatrack (e.g., sequences of notes or “gate” events produced by resettable octatrack designer LFOs that you can modulate with other octatrack LFOs).

in this routing setup the octatrack greatly expands the power of the Pyramid in completely optional ways: these auxiliary functions don’t get in the way but are always available when you want more interesting modulation.

also, I use an FH-2 + FHX1 expander for midi/cv, and it’s clocked by the Pyramid (which again is slaved to the USAMO). it receives midi from output A, which could be just pyramid-produced midi events, pyramid + live octatrack produced midi events, or pyramid-produced midi events that include stuff I’ve recorded into the Pyramid from the octatrack.

*I prefer almost always to just sequence the octatrack with itself. all the parameters are much more readily available this way. there are only a few things you can gain from sending events besides clock from the Pyramid to the octatrack, such as probabilistic recorder triggers, arpeggiating samples, or instantaneous pattern changes.


I never sequence the Octatrack from the Pyramid as it is actually better on the Octatrack due to the large number of parameters available to lock on a step, conversely I rarely used the Octatrack midi tracks as the Pyramid is much better for sequencing other gear (although the Octatrack arp is very nice)

But it is very convenient to have control over the Octatrack record buffers from the Pyramid, and for crossfader control via CC as @autopoiesis mentions.