pattern_time rewrite?

[robbielyman]

I saw on lines that there was some energy two years ago around rewriting / extending the pattern_time library. It seems like some of the major proposed features were 1-shot playback and quantization of recording and/or playback.

Is there still an appetite for working on pattern_time? What's the current status of the project / specification? Can we help? These are the sorts of questions I figure this discussion might start by answering :)

[dndrks]

heck yeah, super stoked you bumped this, thank you!!
as far as i can tell, nothing has been worked on yet, but i've hand-spun my own versions of pattern_time for all my own private projects requiring clocking, so i'd definitely be interested in collaborating with others who have needs re: sync + timing manipulation.

just in case any additional reflection on that post in the years since is useful -- in situations where quantized playback is needed, i've mostly been using a 48ppqn clock-driven version of pattern_time, which automatically checks a lot of my boxes from an 'i played this to a beat, please play it back in slightly better time' perspective:

this gets called from self:start()

function pattern:begin_playback()
  if self.clock ~= nil then
    clock.cancel(self.clock)
  end
  self.step = 0
  self.play = 1
  self.clock = clock.run(
    function()
      while self.play == 1 do
        clock.sync(1/48)
        -- // more on this in the text below:
        if self.step == 0 and self.start_callback ~= nil then
          self.start_callback()
        end
        -- //
        self.step = self.step + 1
        if self.end_point ~= 0 then
          if self.event[self.step] and next(self.event[self.step]) ~= nil then
            for i = 1,#self.event[self.step] do
              self.process(self.event[self.step][i])
            end
          end
          if self.step >= self.end_point then
            if self.loop == 0 then
              self:end_playback()
            elseif self.loop == 1 then
              self.step = 0
            end
          end
        end
      end
    end
  )
end

nb. if i have parallel processes that i want to re-start with the first step (eg. linking resets to a driving pattern where all patterns reset if the driver loops back to 0), that script-definable start_callback in the snippet has been useful.

and really, when i just want to record data and play it back in a loop exactly as recorded, pattern_time totally checks those boxes for me. but there are definitely times when extra scaffolding and control are desired -- this makes me wonder if pattern_time can remain the high-accuracy timer / metro-based version of a pattern recorder, with a new + separate quantized module (with beat-synced start/stop, etc) built from this convo?

[robbielyman]

Cool, thanks very much for this!

I guess I don't have needs re: sync and timing manipulation—faeng could use them or get by without, for instance—but I'm down to muddle through anyway.

A small first thought: should 48ppqn be configurable?

I can see the usefulness for having whatever this turns into being a separate module, for sure!

[robbielyman]

Something that's kind of annoying about the way pattern_time works that maybe isn't really changeable is that pattern:rec() is only really useable for the first passthrough, since subsequent calls to it append events with a basically garbage amount of time between them and the previous recording sesh's set of events.

It might be nice for this module to have subsequent calls to rec() (maybe while paired with play()?) actually either overdub or overwrite by default?

[robbielyman]

Hihihi okay I gave this a shot here. Open to suggestions on the name. Originally I was calling it pattern_clock which I hated. The demo script is knockoff earthsea but I gave it a knockoff engine based on PolySub that uses FormantTriPTR. You'll get duplicate engines currently if my other script lamination is installed, but you can safely delete one of the copies of FormantTriPTR.sc in that case. (Trying to see how Zack avoids this problem.)

How it works

So rec and loop (and set_rec() and set_loop()) are simple flags in this implementation.
In order to be recording, you have to have the transport moving, i.e. you need to press start().
The first time you record (or really, whenever endpoint is set to 0),
loop is ignored and the transport will continue rolling indefinitely.
The first time you press stop (or really, whenever endpoint is set to 0),
endpoint is set to the current value of step.

Subsequent calls to start() will be one-shot or looping depending on the value of loop().
Recording is overdub always; I figure it's fairly cheap to set up a second copy of reflection to do "overwrite" things.
Something that's possible within the implementation but not the API is "append" recording.
It wouldn't be too hard to add that, but I don't know whether there's an appetite for it.

Oh, I guess I didn't add messing with the quantization to the demo script.
You can test that out by doing e.g. Narcissus:set_quantization(1/8) in Maiden.
When I was writing this, trying to deal with time factors broke my brain, so I left them out.
Probably not too much of a lift to add them back in, just wanted to get out something working to play with.

[robbielyman]

Bashed my head against stuck notes in xD1 for ages till I figured out that they were really reflection's fault. Should be fixed now. Also FormantSea plays nicely (or should) with the other FormantTriPTR scripts out there now. Any interest in adding a clocked pattern recorder to the mother ship?

[dndrks]

@ryleelyman , rad rad rad! messed around with FormantSea today -- sounds super lovely!
syncing is working really well -- such a joy to be able to slow down the clock and have the pattern respond :)
i really really appreciate the thoughtfulness of your implementation, especially being able to just flip on 'record' as a pattern plays. the clarity of the code is also fantastic!

from a scripting perspective, i'm curious if there's any excitement for / interest in the library supporting the following, or if those should be left to the individual authors:

• a 'queued rec' flag to be able to start recording with the first data pass, rather than as soon as recording is engaged
• methods to duplicate the loop
• a 'start quantization', where the :start() would get called on a specified sync value, rather than only being able to follow the pattern's overall playback quantization -- eg. if i want assurance that the playback will start on the '1'
• a duration option, to be able to auto-stop recording after x beats of recording
• an option to start playback as soon as recording is ended (useful for on-the-fly / performance looping)

happy to help add to reflection with any of the above -- lmk if anything sings to ya!

[dndrks]

rad rad! i'll take a couple passes over the next few days <3
and yes re: duplicating/doubling! though that q inspires wondering if'd be nice to supply a 'copy/paste' functionality, to be able to copy a loop into another reflection so you can have three or four different versions of it.

[robbielyman]

I took a shot at these! I think I'm pretty happy with the implementation for all of them, although strictly speaking queued recording does nothing that a smart user couldn't have scripted already.

One thing I didn't implement was starting playback when recording is finished, although I'd be happy to if you think the following existing solution for it is too heavy for a user of the library. To really nail it, you wanna either hijack the end_callback() programmatically or manually:

narcissus = reflection.new()
narcissus:set_rec(1)
narcissus:play()
-- yadda yadda
-- "programmatically" hijack end_callback()
local fn = narcissus.end_callback
narcissus.end_callback = function()
  fn()
  narcissus:start()
  narcissus.end_callback = fn
end
-- "manually" hijacking it would be just changing it to something like
narcissus.end_callback = function()
  narcissus:start()
end
-- and then changing it back later when you no longer want this behavior.

[robbielyman]

obviously no rush ever about this, but would love your feedback when you get the chance, @dndrks!

[dndrks]

ah jeez i'm so sorry, totally lost track with the end of the year hustle -- will compile notes tomorrow!! thank you so so much 🖤✨

[dndrks]

closing loop here: robbielyman/reflection#1
thank you again for your patience + help + vision!!

[sonocircuit]

following up from a brief convo on lines:

1:

I really like how recoding is set up with the different modes and duration passed on as args. One thing I noticed is that if recording is set to queued rec there is no way to visualise if a pattern is currently queued or not. Typically I'd have something like this in my gridredaw:

  -- ..
    elseif reflection.rec == 1 then
      g:led(x, y, 15)
  -- ..

However, this won't have the desired effect with reflection (because if it's queued it's not recording, right?). As a workaround I added a flag reflection.rec_enabled and used that to reflect the recording state in the gridredaw.

function reflection:set_rec(rec, dur)
  --...
  -- if rec is enabled, even if queued, we'd like to know, right?
  if rec > 0 then
    self.rec_enabled = 1
  else
    self.rec_enabled = 0
  end
  -- ...

2:

Similar to above I like to know if a pattern is currently overdubbing or not, so I added a flag reflection.overdub which is set to 1 if recording is on and count > 0 and to 0 if recording is off.

This might be a niche case or there might be a easy workaround without having to alter the reflection lib, I just thought I'd put it out there.

---

3:

Another thing is that I've run into are sync issues when more than one pattern is playing simultaneously.

In my script I have reflection set up for 8 pattern recorders. I'm assuming like in pattern_time it's ok to use the lib for more than one pattern recorder, right?

pattern = {}
for i = 1, 8 do
  pattern[i] = reflections.new()
  pattern[i].process = event_exec
end

Now let's say I record 3 different 4 bar patterns (set via dur arg). If a single pattern is playing, it's tightly synced to the clock (tested with ableton live, synced via link). As soon as a second or third pattern is playing there is always a sight lag accumulating and so the newly introduced patterns start to drift out of sync. this is also the case when all patterns are started with a quantisation value of 4 (so they all start on the downbeat).

---

4:

Btw I believe the name of the arg in reflection:start(quantization) might be a bit confusing. Maybe changing to count_in or similar would make it easier future scripters.

thanks for looking into this.

[sonocircuit]

Hi there! No worries, thanks for getting back.

1. Great. Yes, makes total sense.
2. Yes, that was my first assumption but then I realised that reflection.overdub == false if reflection.rec == 1 and reflection.count > 0 and "the patterns is being recorded for the first time". right? But as I said, it might be a niche case where differentiating the visual feedback is needed and think it's ok to leave this out.
3. Thanks for looking in to this. I can share my script if it helps.
4. Yes, I totally agree. I guess it's more important that the meaning of the arg is mentioned in the docs than the arg itself.

[dndrks]

hihi! also sorry for delay on my side!!
shweeee! i friggin' love this library, thank you @ryleelyman !!! and so much gratitude to @sonocircuit for giving it spins!

1. currently, the API offers reflection.queued_rec as a way to track the queued state -- here's its use in formantsea.lua. i shorthanded checking .queued_rec == nil since :watch nils it once the events start coming in -- but this does break assumptions of 1's or 0's. it seems useful to have a specific variable to check, rather than remember more than the binary of rec states, so i'm curious if queued state would benefit from having its own 1/0 flag?
2. @sonocircuit, the 'first pass' exclusion is a good point -- i feel like that makes adding .overdub worth investigating, which perhaps might need some local awareness of whether the recording is the first pass or not? this awareness might also be helpful for situations where you might've triggered recording (set_rec flips .play to 1) but then before you add any events you turn it off -- .play remains 1 in this case, because it's not stopped, but is there a reason to have an empty pattern play through if its not recording?
3. oh! yeah, looks like this happens with just one instance as well. for a test, i added print(clock.get_beats()) as the start_callback in formantsea.lua -- with a rec duration of 4 and the pattern looping, i get slipping time:

4500.4810703333 -- first looped playback
4504.522425 -- second looped playback
4508.532703 -- etc
4512.5431933333
4516.5529366667
4520.5635576667
4524.5742813333
4528.5869686667

4. quantization also feels like it could be a boolean, so maybe changing the arg name could also let us clarify that the API is expecting a beat-value? eg. sync_to or sync_value or beat_sync_value?

[sonocircuit]

hiya, hope you two are well.

had some time to tinker with reflections and ruled out the cause for the drifting patterns. when calling rec with dur as arg reflection.endpoint isn't set to the correct value consistently via reflection:end_playback(true). so sometimes it's off by 1 step and it drifts, sometimes it doesn't. my current workaround works, but prob you have a more elegant way of solving this.

basically I'm storing the dur value in new variable (reflection.set_len) when rec() is called and instead of setting the reflection.endpoint with reflection:end_playback(true) it's calculated with reflection.set_len * 96.

[robbielyman]

hiihihihi! i'd love to land this in norns and seamstress. @sonocircuit @dndrks if you have some energy now or in the future to revisit this conversation, i'd love to squash some bugs!

[sonocircuit]

Hiya! Oh, yes great idea. Sorry for not getting back to this earlier... finding it hard to focus on things at the moment. I made a few tweaks to the lib and have had reflection running successfully in one of my unreleased scripts for the past 6 months. I need to compare the two files and see which changes are actually needed. In other words, I'd be happy to help and I'll get back to you with my suggestions later this week.

[sonocircuit]

Hi there.
So, today I got round to go through the reflecion lib and re-check all my changes/additions. Here's a gist with the code, including my comments. For clarity they always start either with NEW: or Q:. Please regard the additions just as suggestions. I find them very useful but I'm curious to see what you think of them. The comments should hopefully be self-explanatory. Let me know if clarifications are needed.
Looking forward to hear from you!

[robbielyman]

really really beautiful work, thank you! will you PR it to https://github.com/ryleelyman/reflection (without the NEW or Q bits except the ones that you feel would be helpful to future travelers)?

to answer your two Q's:

• on seamstress, at least, the following two Lua snippets have different behavior (which is tripping me out); this is why I removed the clock.cancel statement from begin_playback. actually, it might be nice to refactor begin_playback so that it must be called from within clock.run and call that out in a comment.

function start()
  if Clock then
    clock.cancel(Clock)
    Clock = nil
  end
  Clock = clock.run(function()
    clock.sleep(2)
    print "hi"
  end)
end

-- prints "hi"
Clock = nil
Clock = clock.run(start)

-- never prints anything
Clock = 6
Clock = clock.run(start)

• yes, what you say about the self.step = self.step - self.endpoint being equivalent to self.step = 0 is true... maybe it would be clearer to replace that.

[sonocircuit]

thanks! glad I could help. this lib is so great, I've been having tons of fun so far. I just sent you a PR. thanks for the explanation. that is weird!

so that it must be called from within clock.run

isn't that what currently happens, as begin_playback is called fromreflection:start()which cancels itself once done?

self.clock = clock.run(function()
    clock.sync(beat_sync)
    self:begin_playback()
  end)

maybe it would be clearer to replace that

Great. I changed self.step = self.step - self.endpoint to self.step = 0