quantized live-sampler isn't computer tight? whats wrong?
so i’ve made this 4 track sampler that quantizes to a metro object before it will start or stop recording.
the problem is: it isn’t computer tight. it loops a couple of 100 milliseconds to early and i can’t figure out why?
i’m quite a noob so maybe i’m doing something really obvious totally wrong.
maybe it has to do with the organization of the patch. if anyone can look at it and tell me why it isn’t doing what its suposed to or tell me what to do i would be really helped.
(i’ve included the patch)
It’s important to understand that the toggle object does not output bangs, nor does it necessarily turn things on; all it outputs are integers (usually 1s and 0s, but it will pass any integer). It can also output a value repeatedly without showing any visible change, which can often cause problems unless checked with a change object. In subpatches sample1, sample2, etc., the toggle under comment "Record" is going to start sending zeros (and lots of them) as soon as you touch your midi controller. The onebang interprets these as bangs, so it opens up its left inlet and lets a bang through on the next quarter note, which may be earlier than you wanted since (I assume) the controller value is supposed to be at 127 in order to trigger this. A bit further down the chain, you have another toggle connected to a message box ("startloop"), and again, a 1 OR a 0 will trigger output in a message box. This is all to say that the whole quantization thing is basically bypassed by your (incorrect) use of toggles. You can work around this by adding some more select objects, or better yet, a togedge.
thanks for the hint but i still can’t figure it out. i tryed to put changes after the toggles used and putting togedges instead of toggles in it but the problem stays?
and it seems that whatever i do, the deviation of the loop stays always the same.
could you make an example in one of my subpatches and maybe try it out yourself? (ignore the midi)
anybody? i’m really stuck. can’t go one with my patch untill this works like it should.
Perhaps you might consider posting what
you did in relation to Steven’s suggestions.
Your original errors were sufficiently basic
that, on seeing your response, one might direct
you to the specific areas in the tutorials where
you could learn/re-learn the bits you didn’t
get. Perhaps not, but – in general – you will
always get better answers to more specific
questions. Always always always.
Quote: nit wrote on Mon, 08 September 2008 12:09
> thanks for the hint but i still can’t figure it out. i tryed to put changes after the toggles used and putting togedges instead of toggles in it but the problem stays?
> and it seems that whatever i do, the deviation of the loop stays always the same.
> could you make an example in one of my subpatches and maybe try it out yourself? (ignore the midi)
it seems like it’s is plabacking faster then recorded?(i’m testing this by recording the transport click and playing it back woch should work). i just can’t figure this out, i’m really stuck.
tried to reorganize the patch with a trigger object(to control what gets triggered first and so on) and with some change and select objects. but nothing helps. i’m quite a noob if that helps you understanding. could somebody reorganize my patch and tell me what i did wrong cause i spent hours and hours on it now and it’s getting a bit depressing.
the attached file is what i ended up with trying to fix this problem. (the left above patch is the one i changed (sample1).
One thing I’d certainly take a serious look
at in the very early tutorials would be the
route object. It would clean a crapload of
cruft out of the patch [i.e., all those ctlin
and sel objects].
Forums > MaxMSP