Sending 'set' messages with the same value create audio clicks (RENAMED)
Opened this issue · 7 comments
Steps to reproduce:
Create a [buffer~]/[karma~] combo. Send a message of 'set basic 0.5 0.5'.
Actual results:
Phasor locks up (see comments below).
Expected results:
Not sure the best course of action here. Maybe it can default to a minimum 'initial loop' value. I like that a window can be set to be a single sample big (for use with modular/dc offset shit), but there's no use for a whole LOOP to be 1 sample long. So maybe the minimum value that can be sent is x amount of samples big?
Comments:
Of you send a jump message this ‘unsticks’ the phasor and somehow defaults to a previous buffer ‘set’ size.
This is kind of working as of commit 3ee990b in that it throws up the following error when you try to set basic 100. 100.:
karma~: loop size (loop maximum minus loop minimum) cannot be this small, minimum is vectorsize internally (currently using 64 samples)
But, if I send a message that it is happy with (set basic 100. 104.) it doesn't define a 4ms initial loop, but instead defaults to what sounds like a 100ms default size.
Is there some internal clamping going on here?
Aside from the potential clamping issue, perhaps the better behavior here would be to throw up the yellow error as it currently does, but if the requested set loop size is < the current vector size, it sets the loop size to the current vector size AND throws up the error message.
Commit 7cb20ca improves this but still some clamping type thing. Or this could be still related to #16.
Sending basic 100. 100. throws up the appropriate message:
karma~: loop size cannot be this small, minimum is vectorsize internally (currently using 64 samples)
But it sets the sample length to 100.725624.
If I set basic 100. 101. it gives me a new loop length of 101.723356, and basic 100. 102. gives 101.995465, so there's some funky remainder thing going on.
Like I said though, this could all be related to not being able to set a lower parameter.
Reopening this one though this may very well be a different problem/bug.
When you send basic 100. 100. it throws up a message as it should, and then karma~ internally sets the phasor to 0.0.
The problem comes that when you then send basic 100. 200. it instantly jumps to whatever phasor position the new set message wants to jump to, but since the phase was set to 0.0 (as viewable by the new spiffy @syncout 1) there's a click.
Maybe the basic 100. 100. message should throw up an error, but remain frozen in it's current phase position. And also continue playing from there when a subsequent set message is sent.
zero loop size now simply ignored, so playback not interrupted. the playhead functionality you want here may not be possible until version 2 rewrite. if you are ok with soft fix i'd be inclined to close this issue. if not, speak up :)
i think this is related to #61
Yeah this can get closed and revisited. I think the ideal behaviour is ignoring the message either way, since this wouldn't be the way to get a single frozen sample either way (ala window 0.0).