Hi Dimitri
While Christopher is of course correct, there's no reason if your
sample rate always stays well under your composition FPS that you
can't sample data at a fixed rate and 'play it back' at the same fixed
rate. One would use Patch Time/ Stopwatch and Pulse patches to trigger
sampling and playback. Thereby keep it disassociated with frame rates
(as much as possible).
It's just like musical sampling happening on CPUs that might get
bogged down from time to time but the sample rate is so much less than
the CPU execution frequency it doesn't matter, the sampler always gets
its man.
Unfortunately I'm on Leopard and couldn't do too much with what was
left of your comp when QC attempted to open it minus a few patches.
If you require sampling that is faster than what your hardware can
demand of QC (ie FPS) then yes, as Christopher says, roll your own
plugin/application to feed QC the data :-)
Hope that gives you some hope.
Alastair
On 13/01/2011, at 2:42 AM, Dimitri Delcourt wrote:
Hello Christopher and Vade, thanks for your replies.
My question might be of general interest, so i'm posting the basic
composition here. It will show some light on what i'm trying to do,
recording gestures in real-time and loop-synced with musical beats.
Christopher, you will see that i am manually step-filling the queue,
i may be mistaken in trying to use it as a buffer the way you would
do it in Supercollider. It would be a nice addition to be able to
select a custom filling frequency, it would be finite and not frame
dependant.
I'm having a hard time trying to figure how to fill a queue in real-
time and read it back with the same duration. (frames unfortunately
do drop some times).
dimitri
<QueueLoopOverdub_(1D)_B.qtz>
On Jan 10, 2011, at 1:48 , Christopher Wright wrote:
Could someone clarify if the queue actually updates between frames
and if there's an advantage in evaluating "continuously"?
no, it wouldn't be possible to update between frames, because there
are an infinite* number of moments between frames, so the queue
would fill with an infinite number of values.
The advantage to evaluating continuously is that you'll essentially
always have a full queue, with per-frame values stored at each
index (so you can access the output in standard N-1 form to get the
previous frame, N-2 to get 2 frames back, etc) instead of per-
change values. some feedback-like effects are frame driven, so
accessing values per frame makes more sense. In fact, I can't
think of any times I've wanted a queue _not_ in continuous mode,
but there's probably a novel use out there somewhere.
*) actually, there are probably only about 1/planck time moments,
so that'd be maybe 1.854 x 10^43 instants. not quite infinite, but
pretty big none the less.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/qc.student.au%40gmail.com
This email sent to qc.student...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
