cudnylon

Still trying to come up with a sequencer I'm happy with. Right now I have a 16-step phasor driven sequencer. The phasor's output gets multiplied and clipped so that it outputs 0. - 1. sixteen times. Unfortunately for my current patch I have to convert this to bangs to trigger the "startloop" for [groove~] which then plays back the selected part of the file using a grain window for the envelope (controlled by the loop sync output of [groove~].

In summary, it goes audio-rate to bangs and back to audio-rate. I want it to work at audio-rate for the entire sequencer. Is there a way to make [groove~] playback the selected loop using a signal trigger of some sort?

My objectives for this patch is to have a buffer I can playback at a variable speed and only specific segments/loop, triggered at audio-rate. A grain/glitch drum machine.

Here is the patch as it stands now, and I apologize for any incorrect terminology used previously. Just select some beats in the matrix, turn on dac, and press start.

In summary, it goes audio-rate to bangs and back to audio-rate. I want it to work at audio-rate for the entire sequencer. Is there a way to make [groove~] playback the selected loop using a signal trigger of some sort? 

Here is the patch as it stands now, and I apologize for any incorrect terminology used previously. Just select some beats in the matrix, turn on dac, and press start.


start-groove-with-signalclick-for-granularglitch-sequencer

instead you must find your solution with index~, play~, or wave~(i recommend index~ or play~(wave~ seems to have a slightly lesser quality interpolation than the rest in my 'opinion'))

It is clearly stated in the reference manual that 

 does NO interpolation. And you can hear that.

It is clearly stated in the reference manual that index~ does NO interpolation. And you can hear that.


You can *sort of* get groove~ to trigger sample accurately. If you set up a load of them and send the startloop message when their associated sig~ is at 0, then when you toggle the sig~ to 1 (or you could use a click~ and sah~ or some sort of comparison object on another signal to transition from 0 to non-zero) then they will begin playback sample-accurately. So if you had a load of them hooked up to the same sig~, it is possible to get them to play back perfectly in sync. Regarding the index~ thing, the whole point of it is that it does no interp at normal speed playback. It gives you the exact sample-for-sample playback of a buffer if you don't need to faff around with variable speed.

@Cudnylon, you may be able to achieve what you want to with groove~ as long as you find a way to startloop each groove~ every time it's playback signal is at 0. Although, I've spend long hours making sample-accurate patches, and came to the conclusion that in most cases there isn't any need for it. Unless you're wanting to get a sequence going and then speed it up incredibly fast, my opinion is that the accuracy of how you've done it already won't be noticeable. If you make sure you have overdrive on you'll have a very accurate sequence going. Another thing to think about is that little timing discrepancies can actually be essential (in my opinion) to create a good groove in music. Rock solid metronomicity (haha I sense this is not a word) just doesn't sound natural.

But if you do want it fully sample-accurate then ultimately using groove~ will always be something of a workaround. It would be easier to think of a way to re-design the patch to use play~ (if you want to vary the speed) or index~ (if you don't).

You can *sort of* get groove~ to trigger sample accurately.  If you set up a load of them and send the startloop message when their associated sig~ is at 0, then when you toggle the sig~ to 1 (or you could use a click~ and sah~ or some sort of comparison object on another signal to transition from 0  to non-zero) then they will begin playback sample-accurately.  So if you had a load of them hooked up to the same sig~, it is possible to get them to play back perfectly in sync.  Regarding the index~ thing, the whole point of it is that it does no interp at normal speed playback.  It gives you the exact sample-for-sample playback of a buffer if you don't need to faff around with variable speed.

@Cudnylon, you may be able to achieve what you want to with groove~ as long as you find a way to startloop each groove~ every time it's playback signal is at 0.  Although, I've spend long hours making sample-accurate patches, and came to the conclusion that in most cases there isn't any need for it.  Unless you're wanting to get a sequence going and then speed it up incredibly fast, my opinion is that the accuracy of how you've done it already won't be noticeable.  If you make sure you have overdrive on you'll have a very accurate sequence going.  Another thing to think about is that little timing discrepancies can actually be essential (in my opinion) to create a good groove in music.  Rock solid metronomicity (haha I sense this is not a word) just doesn't sound natural.

But if you do want it fully sample-accurate then ultimately using groove~ will always be something of a workaround.  It would be easier to think of a way to re-design the patch to use play~ (if you want to vary the speed) or index~ (if you don't).


is play actually more accurate than groove? thats surprising, i had it the other way round in my head.

No, groove~ interp is *nicer* than play~, but it can be a less useful object in many situations. Just do a test with each object, a spectroscope and good speakers and you can hear which sounds more transparent. If you want really good vari-speed playback search the forum for resample~. It's from Volker Bohm and uses sinc interp rather than linear or cubic, and as such still sounds really useable even at rediculously slow playback speeds.

No, groove~ interp is *nicer* than play~, but it can be a less useful object in many situations.  Just do a test with each object, a spectroscope and good speakers and you can hear which sounds more transparent.  If you want really good vari-speed playback search the forum for resample~.  It's from Volker Bohm and uses sinc interp rather than linear or cubic, and as such still sounds really useable even at rediculously slow playback speeds.


That makes sense. It's also a reminder that I should try to refrain from answering things I know little about!

That makes sense.  It's also a reminder that I should try to refrain from answering things I know little about!

that's for all the advice an discussion. I decided to stick with my current timing method to prevent being too rigid and also send triggers relative to the sequencer to other modules in the patch.

After looking into phasor~ it seems that locking it to transport and using time values while sending the BPM to transport would give better results/control, while using rate~ connected to the master phasor~ for time divisions. Is transport getting it's timing from a metro though? In that case I might not bother locking my master phasor~ to it.

edit: nevermind, the reset message to transport sends out an extra click which my current method doesn't feature.

Start [groove~] with signal/click (for granular/glitch sequencer)