mimicking buchla MARF time interval per step function?

hi all ~ i’m currently working on a fixed rack in vcv that would satisfy most of my improvisational interests. after watching pyer’s expertly detailed take on suzanne ciani’s cookbook link here and her innovative use of the buchla MARF (or 248, the multiple arbritrary function generator), i decided i wanted to bring some of this magic to my own sets.

i’ve been able to recreate pyer’s vcv interpretation of the MARF, and made a VERY scaled back version of my own incorporating an old BCR-2000 midi controller and vult’s dopamine module for a level of live modulation and looping (thanks to vcv-rack-ideas for that concept). one aspect of the MARF i am having trouble mimicking though, is the “time interval per step” function.

i’ll attach a sample of my approach so far below, which uses a bogaudio addr-seq to address the shapemaster pro’s length input which then sets the step length for several sequencers. from what i can tell, unsynced it works pretty much as you would expect - set a length on the addr-seq, get to that step and shapemaster’s length changes which in turn sets the clock for the sequencers (cool cool).

i was, however, hoping to utilize the shapemaster’s clock sync/lock function to make the step lengths be set intervals (as opposed to free running), yet i can’t seem to get it to act consistently, and/or i don’t entirely understand the behavior behind the “lock” function. best i can describe, it seems to get stuck at smaller gate times (<1/16, say) and is delayed by a step when using longer gate times.

maybe this is a question best posed to the mindmeld folks? if, however, anyone would like to take a look at my implementation so far and provide some feedback, that would be super appreciated! it would both be nice to chat with others about this subject and it would help me refine what i have so far. and suggested alternatives are welcome!

thanks much ~paloma

patchstorage link to patch

1 Like

Hello and welcome! :slight_smile:

This is a super-interesting:

  1. concept
  2. patch
  3. question

and thanks for posting it! Lacking any immediate insight or relevant expertise I’m going to dive in as I suspect that, worst case, I will learn something…


Great 8-bit game over sounds when it gets stuck at a small division!

The main behaviors I notice when playing around with a single step in STEP LENGTH are:

  1. Long lengths (> 0) often don’t take unless multiple steps in a row are set long;
  2. Short lengths (< 0) often affect multiple subsequent stages;
  3. Very short lengths seem to get stuck, just as you describe, often not resetting until all lengths are back at 0.

I’d defer to @steve and @marc_boule but I think it has something to do with this detail (p. 5 of the manual):

When sync lock is on, triggers and length changes are quantised. They are treated as ‘early’ and the action will take place on the next ‘main’ clock pulse. Eg. with a length of 1/4 at 48ppqn, pulse 1 of the 48 is the ‘main’ pulse.

Let’s look at behavior 1 first. Say that Step 2 on STEP LENGTH is set high (+1V in the range you’re using) and everything else is at 0. When Step 2 is reached, that tells Shapemaster Pro that the next cycle should be long, but (because of Rack’s one-sample delay) it gets this after Shapemaster Pro has already started a cycle at the previous length. And once the current cycle finishes, it moves STEP LENGTH to Step 3, resetting the length.

I suspect that something similar is happening for short settings (the cycle gets so fast that it doesn’t receive the update in time) and very short settings (as with short settings, but the relative timing never ends up resetting).

I also suspect that the unpredictability is because the sequencer is basically racing with the 48ppqn “main clock” to see who gets to update Shapemaster Pro first.

So, maybe a step towards a diagnosis, but no solution…

what a video! GREAT :pray:

Hi. I might be completely off topic here, but I was wondering about the same thing the other day (controlled synced clock length). Would a CV controlled clocked divider not work better (I know there is one from Count Modula, or Bogaudios Rgate). You can then control the clock division with the Addr seq. I havnt tried it yet so its only theory.

This will likely be quite a long post so…

I’d like the shortest answer possible!

Turn lock off (while keeping sync on).

OK maybe a little more guidance would be useful…:

Are you manually triggering channels and making manual length changes that you want to be quantised? Turn lock on.

Are you triggering channels with clocked sources and making sequenced length changes? Turn lock off…

Are quick length changes your priority? Turn off “Playhead never jumps” and make sure “Sync lock quantising” is set to “Max 1 bar” (in channel settings)

Is smooth modulation your priority to avoid clicks/pops due to fast and steep changes in voltage? - Turn on “Playhead never jumps” (length change can only happen at end of cycle)

Is maintaining Swing quantisation your priority when modulating cycle lengths? Make sure "Sync length quantising is set to “Quantise to cycle length:” (may lead to long delay before change occurs)

I like reading long things and really want to understand more about what’s going on…

Well if you’re sure… :slight_smile: The effect of sync lock on length changes goes, by necessity, quite deep. There is a section on it in the manual but in truth this one feature could almost have a manual all of its own. Marc and I spent many nights melting our brains trying to figure out how it should behave in different scenarios often thinking we had solved it only to then go something like 'but what if we are changing from a long length like 4 bars to a short length like 16th note, we have negative swing on the channel, and bpm is being modulated at the same time? - when should the change occur in order for everything to stay quantised?

Having said that there are a few simple principles that hold true which should help. The first is that the main purpose of sync lock is to quantise MANUAL triggers and length changes. A manual trigger being something like a button cabled to a channels trigger input and manual length changes being what happens when you manually turn the length knob. If you are triggering and/or doing your length changes with a clocked sequencer, then you probably want lock turned off as quantisation is unnecessary (it is being handled by the clocked modulation source). With lock off, any trigger or sequenced length change will happen immediately (within 1 clock pulse), which can throw things out of time, relative to your song or other locked channels, if being done manually, but should stay in time when being triggered/sequenced by a clocked source.

There are a few other things to bear in mind. To account for swing (which may be added at any time) we need to deal with PAIRS of cycles (as with swing, for each pair of cycles, one cycle length is shorter and the other longer. This means that depending on whether you make a length change on the first cycle in the pair or the second, you may have to wait an additional cycle for the length change to occur (the pair needs to complete).

There are two other controls in the channel settings menu that also affect the behaviour:

“Playhead never jumps” - when this is active, a cycle (or pair of cycles) must complete before a length change can occur. This will prevent clicks due to sudden steep changes in voltage when you are using a shape for modulation for example but will lead to delays before length changes. If the playhead is allowed to jump then changes will happen much quicker (but may lead to clicks/pops) - set this according to what your priority is - responsiveness Vs smoothness

“Sync lock quantising” - Shapemaster is constantly counting clock pulses and when sync lock is on, it quantises actions to “main” clock pulses (as described in the quote from the manual g3C above). The “Sync lock quantising” control determines how it does this. There are two options - “Quantise to max 1 bar” and “Quantise to cycle length”. When cycle lengths are 1 bar or less, they are always quantised to cycle length (so at 48ppqn with a length of 1/4 for example, pulse one of each group of 48 pulses is the ‘main’ pulse. However we realised that for long cycle lengths like 64 bars for example (which in this case means a main pulse would be pulse 1 of each group of 6,144 pulses…), quantising to cycle length may lead to unwanted results (if you make a length change 2 bars into a 64 bar cycle, you would have to wait another 62 bars, plus potentially another 64 bars (to account for swing) before the length change happens - therefore the “Quantise to max 1 bar setting” allows the length change to happen within 1 bar even for long cycle lengths. The downside of this setting is that if you have swing enabled, your swing quantisation will likely be lost (whereas it is maintained when quantised to cycle length). Again set this according to your priorities - responsiveness Vs maintaining quantisation of channels with swing.

One other thing to mention about sync lock is that while it does generally treat all triggers as early - it also gives you a short ‘grace period’ to account for small delays introduced by Rack cables. You can actually trigger a sync locked channel up to 50 samples late and it will still sync to your ‘intended’ main pulse that already just happened rather than waiting to sync to the next one. This only applies to the trigger inputs and not knob modulations though iirc.

As I said this does all get quite deep and we lost more than a few hairs figuring it all out and coding it. However the final result is both flexible and robust and you can set it to behave however you want depending on what your priorities are. And again, the lock behaviour is only really relevant when making manual changes anyway (as you might in a performance for example) - if you are sequencing length changes with clocked sources you can just turn lock off and forget about it. While it was complex for us to pin down and code the lock behaviour as we had to account for all sorts of outlier scenarios, in practical use it’s actually quite straightforward.

Simple Sync Lock demo patch

I made this little patch to demo sync lock and it might help get your head around the behaviour (and it allows you to do some pretty cool things with drums! On channel 1 there is a kick drum - think of this as just a metronome keeping time. On channels 2 & 3 there is a rim shot - channel 2 has lock on and channel 3 has it off. Start with channel 2 and (mute 3) and mess around with the length knob while it is playing - you can be brutal with the knob going from fast lengths of 1/64th to slow lengths of 2 bars (or longer if you like) and finally end up back where it starts on 1/4 - the rim will end up perfectly in time (sync locked) with the kick where it started. Now try adding some negative swing to channel to - say -25% - and mess with length again - still all good!. Now mute channel 2 and do same thing with length changes on channel 3 with lock off - length changes will happen quicker as they can sync to any pulse rather than ‘main’ pulses but when you end up back on length 1/4 the rim will likely be out of time with the kick.

Channels 4 and 5 manually trigger a high hat using the Little Utils button module. Channel 4 has lock on and channel 5 has lock off. With lock on the trigger will be quantised so the hat will hit at same time as kick (regardless of when you press the button). Whereas the hat on channel 5 will be triggered immediately with lock off.

lock demo - drums.vcv (43.9 KB)

1 Like

If I understand correctly how it should work, then this seems to do the trick? - just needed to turn lock off

I also changed the v/oct VCO source to a constant tone so it makes the rhythm easier to concentrate on

paloma_marf_intperstep_demo-steve.vcv (108.3 KB)

When lock is on, a cycle length of say 1/8 is quantised to 8th notes meaning it can only start on an 8th note. Therefore if the previous cycle length was something fast like 1/32, that fast cycle will keep repeating until the 8th note cycle can start which may explain the behaviour you were seeing when you said it got ‘stuck’ at shorter cycle times.

1 Like

@gc3 @ale47p @auretvh @steve

thank you all for the response/interest! it may take me a minute to respond to each of you in kind, but i’ve been reading your comments and they are very much appreciated. i think i am starting to understand more about the modules i’m using for this and what kind of behavior to expect from them.

i also spent some time last night extending the demo patch i posted to include two playheads as pyer demonstrated. ill post the update to patchstorage later (also maybe a short recording?) - small steps towards something big! :smiley: :+1:


Hi paloma,

Not sure how granular you want to be, but you can emulate variable time per step simply by clocking the sequencer from a separate gate sequencer (eg a Gate-Seq-64). Of course, this only allows integer subdivisions of the pulse, which may not be what you want.

Best Regards, Chris.