Page 2 of 2

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 8:24 am
by IXix
I've just found this that I saved in a text file, from a BuzzChurch thread I think. Unfortunately I can't remember what the question was. :(
oskari wrote:Subticks can have different lengths. You should send the control changes in Work when PosInSubTick is 0. If you build your event list in Tick you can then do something like this in Work:

if (PosInSubTick == 0)
{
// process Events[CurrentSubTick]
// this block gets executed once for each subtick
}

You don't have to count samples if you just use CurrentSubTick.

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 8:40 am
by UNZ
but if you calculate your LFO to correctly update in all cases (not just when pos_in_subtick ==0), taking into account the different (current) lengths of a subtick, it should be the same but at reduced latency and possibly increased resolution imho, you do indeed have to count samples then tough i guess.

what i mean is: taking into account pos_in_tick and pos_in_subtick when calculating how much the lfo phase has to advance every work call (and send every work call). i actually think you don't even need pos_in_subtick or even pos_in_tick for this and simple advance by the numframes in work. that is what i am doing now, which seems to work...

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 8:58 am
by IXix
UNZ wrote: Mon May 11, 2020 8:40 am but if you calculate your LFO to correctly update in all cases (not just when pos_in_subtick ==0), taking into account the different (current) lengths of a subtick, it should be the same but at reduced latency and possibly increased resolution imho, you do indeed have to count samples then tough i guess.

what i mean is: taking into account pos_in_tick and pos_in_subtick when calculating how much the lfo phase has to advance every work call (and send every work call). i actually think you don't even need pos_in_subtick or even pos_in_tick for this and simple advance by the numframes in work. that is what i am doing now, which seems to work...
That makes sense but I've never really understood how the whole thing works anyway. :lol:

I think I have an archive of BuzzChurch on an external drive, so I'll see if I can dig up the thread later (supposed to be home schooling now :()

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 9:15 am
by UNZ
i've written out the parameter values as wave files to compare peer lfo with my new lfo test. testing at 1hz.
it looks pretty close, but doing it my way results in a slightly cleaner sinewave. see FFT of the output comparison in attachment. Blue is peerlfo, red is my new one. the difference isn't big tough.

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 9:22 am
by UNZ
ok at 10 hz, peerlfo actually aliases more on average (higher spikes) and you can see more staircases in the waveform by eye even than doing it my way. the noise floor in my version is higher because of the jitter, but i think overall lower spikes are preferable.

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 9:28 am
by UNZ
here it is at 10hz in time domain. peerlfo at the bottom.

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 10:32 am
by UNZ
i'll have to test this some more, as i think it's possible to make it even a bit smoother, for some reason some work() calls don't seem to get updated parameters yet i think, have to properly timestamp / count and see.

all in all: it might not be worth the effort to change anything in peer machines. but what we can do is the following:
control machine work gets called before any other machine's work, so if we made peers write the lfo into a buffer at audio rate, and made a little interface for receiving machines to get to that buffer (could also be done via aux), we can have perfect audio-rate modulation, bypassing all the tick nonsense. receiving machines would have to be updated, but it would be quite a simple change (it would be a bit like an opt-in some machines do with peertune). why not just use audio inputs / outputs then ? well, we are still targeting "parameters" (altough we don't write to machine state, receiver applies buffer directly to his buffer), so your generator doesn't have to have inputs if we do it via aux (or new protocol)!

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 12:25 pm
by flat
IXix wrote: Mon May 11, 2020 8:58 am I think I have an archive of BuzzChurch on an external drive, so I'll see if I can dig up the thread later

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 12:28 pm
by flat
subticks2.jpg
subticks2.jpg (330.1 KiB) Viewed 7250 times

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 2:08 pm
by IXix
Thanks flat! 2008! :lol:

Re: PeerLFO - Updated 7th June 2018

Posted: Mon May 11, 2020 2:43 pm
by UNZ
thanks for these, very helpfull!

can you find the thread where it says "see THIS THREAD" too :) ?

Re: PeerLFO - Updated 7th June 2018

Posted: Sat Jun 13, 2020 10:24 pm
by synthphase
For what it's worth, I would want no noise-floor, even at higher frequencies. Having less random noise overall though would be great. I don't imagine peer stuff can work at the audio-rate can it?

Re: PeerLFO - Updated 7th June 2018

Posted: Mon Feb 22, 2021 12:30 am
by River Cricket
A minor semi-bug and solution I just worked out - posting here mostly so it might come up in a search if someone else has the same issue (or, probably even more likely, I have the same issue again and forgot how I solved it :D)

PREAMBLE:
"Random" (and "Square", to some degree) can be seen a little bit differently from the other wave types in how "Rate" works. Sine, Saw, etc, are continuously updating (at a rate determined by the Update Frequency in Peer LFO - default is 1 tick).

Because "Random" is a constant, however, it only updates once per Rate. Update Frequency (as far as I can tell) has no effect.

PROBLEM:
When using "slower" rates, it's possible for "Random" to become quite audibly detached from actual song measures. For instance, a Rate of 32.0 (once every two bars) could end up with new positions on the 12th Row of a Pattern (and then again on the 44th Row, and the 74th, and so on) - this could be interesting for polyrhythms, of course, but generally one would prefer each new position to come at the 1st (or 0th, to be technically precise I suppose) Row (and 32/64 or 33/65 Rows, and so on).

Basically, the way Peer LFO decides when to update "Random" is to count upwards from 0, with a modulus of whatever the "Rate" is. Once it hits "0" again, it gets a new "Random" value. However, critically, Peer LFO never forgets what number it's on, and that number is free-floating, not tied to the position within the overall track. This means that if Peer LFO is set to Heed Transport and you stop playback at, say, the 20th Row of a Pattern, then go back and play the song from the beginning, Peer LFO will start counting at "21", which will result in the "desynced" behavior I described above - updating 12 Rows off the start of a new Pattern.

(If Peer LFO is not set to Heed Transport, then where exactly it will start from is basically random for human purposes, since in this case it's counting constantly behind the scenes)

rePAIR:
In order to force a proper alignment of Random values, you must set Peer LFO's manual phase to 100% at the start of a track. This, of course, only works when playback begins at the start.

Note: Setting it to 0% can also work, but if you're looping back to the beginning, this will result in occasional minor glitches, where Peer LFO decides on a new value, starts heading towards it, song loops, Peer LFO gets zeroed, decides on another new value, and heads towards that one instead. Setting it to 100% ensures that Peer LFO won't change its mind out-of-turn.

(the upside of setting it to 0%, however, is that then you can just say "zeroing the value", which flows off the tongue so much more easily, doesn't it? :P)

POSTAMBLE:
Obviously, this issue also affects the other waveforms too, in that the peaks will occur at different parts in the song. However, because Random updates less frequently than other waveforms, it can create more drastically-improper results. For instance, when assigning Peer LFO to the Note value, with manual note offs in the slaved machine's pattern, you may be left with too-long silences and too-short notes, since the Note event only fires once Peer LFO changes position.

Re: PeerLFO - Updated 7th June 2018

Posted: Mon Feb 22, 2021 2:40 pm
by IXix
Phase 0% should be the same as 100% unless I'm very much mistaken. Glitches will happen whenever you set manual phase to anything while playback is happening. You can use inertia to smooth the transitions.

Setting the phase at the top of the track is a good idea if you want repeatable results but you can set it to any value that suits you, it doesn't need to be 0% or 100%.

Re: PeerLFO - Updated 7th June 2018

Posted: Wed Feb 24, 2021 4:11 am
by River Cricket
IXix wrote: Mon Feb 22, 2021 2:40 pm Phase 0% should be the same as 100% unless I'm very much mistaken. Glitches will happen whenever you set manual phase to anything while playback is happening. You can use inertia to smooth the transitions.
It took me by surprise, too. I originally tried 100% as just a random initial step. It worked, I went to write up the immensely-long post, then while writing it thought "you know, maybe I should just say 'set it to zero' so I can refer to it as 'zeroing out'" (hence that little aside :D). I then tried setting it to 0% and discovered the behavior.

I peeked into the source but I'll admit I got distracted once I figured out to just set the Phase to 100%.

What's also interesting is creating a PeerLFO pattern that continuously (i.e., every step) sets the Manual Phase to a particular number. 0000 and 7FFF both work as "expected" - creating a new Random result at every step. Phases greater than 0000 also work as "expected" - locking the current Random result as-is, regardless of Rate.

However, numbers greater than 7800 - 93.8% - will trigger the new Random result at every step behavior, just like 0000 and 7FFF, and spamming a Pattern full of 7800's - not 77FF's or 7801's - will create a new Random result at what sounds/looks to me like every other Step. Valuable information, maybe?

Anyway, digressions aside, I've attached a .bmx file using PeerLFO and Green Milk. The PeerLFO pattern starts at 0%. Keep an eye on the Filter Cutoff in Green Milk while the song loops and you'll see the numbers glitch out every time the song loops back to the "1" / row 0 / C-4. You'll occasionally hear it too, of course, when the values selected are wildly different from each other.

Changing the PeerLFO pattern to the one labelled "100%" solves the glitch.
IXix wrote: Mon Feb 22, 2021 2:40 pm Setting the phase at the top of the track is a good idea if you want repeatable results but you can set it to any value that suits you, it doesn't need to be 0% or 100%.
For non-Random waveforms, yes (though obviously this will switch the "peak" position - whether it's on the downbeat, the 2, the 3, etc).

For Random waveforms, also yes, but because Random only switches once per Rate, this can create more jarring an effect if you're counting on the PeerLFO to be in time with particular notes (which you might do when, for instance, emulating the "random articulation" feature of an ARP Odyssey, where each note has a different, random filter cutoff) or using PeerLFO to generate notes which you're expecting at certain places within the song.

Re: PeerLFO - Updated 7th June 2018

Posted: Wed Feb 24, 2021 9:07 am
by IXix
Oh that's surprising. I'll try to look into it eventually but I'm super busy now.