Support
Looper's Delight
|
Support |
|
|
>Matthias Grob wrote:
>>So if you want to record a full attack, you need to press the
>>button about 7ms before you play it - which does not seem to be a
>>problem for anyone.
>
>When I record into software, I delay the audio signal by the
>fadetime, and can then even hit exactly on the point without missing
>any attack.
ah, ok, once you accept some latency by the HW anyway, this is a
slight increase.
>I am recording always, it never stops, when I want it to go into a
>loop, I route the delayed signal to the place I need it. This
>artificially introduced latency never hurts, but I need less
>practice for being on time.
>As instead of me learning how much I have to be in advance for a
>trigger, my software learns how much I am usually late if I feel I
>am on the "groove"...
great!
>you are exagerating.
I am not sure what you mean, but anyway
I am aware that the EDP method can be improved but its not an urgent
issue because I hardly remember anyone having complained about it.
In general I wonder how much we can improve the technology to make it
easier for the musician. I think that one of the reasons why looping
is not big in the world yet is that we still rarely see a show where
the looping is perfect and does not cause any sorrows or unintended
musical fixes. Most of us (musicians and public) dont mind or even
like such interferences, but its still hard to imagine that a
musician would risk to loop five minutes at the opening of the
olympic games for example.
from this thread, my confidence grew that the PC may become more
important than dedicated hardware soon. The tricks you are talking
about can be created on hardware, too. But its easier on the PC and
we got the screen to show states and loop contents better and all
kinds of ports to interface with instruments, controlers, video...
The same loop tool can be used in a cheap laptop with the internal
sound converters for a live job and for recording in a multitrack
high quality studio, where its easier to keep sync between many
musicians and record all time information and sound fragments to
create an optimized final mix.
And PC hardware is a available in a variety of quality and price in
the whole civilized world, which will give looping a boost in the
third world.
But still, there is a lot of programming work to do and it seems hard
to make money from it :-(
>
>I know, ;-)
>
>>to trigger with audio is not that simple. Andy and me spent quite
>>some time to figure it out for the Mathons plugins. Its never
>>within a sample. And we want foot operation, and I doubt that a PC
>>can garantee 1.5ms for that. But there is no need. Praxis counts!
>
>I think if you just deliver a dc (a switch with a battery), even to
>an audio interface which does not pass dc itself, you should easily
>detect this loud click and use it as a trigger.
sure, I had not understood audio trigger this way. Interesting
idea... the foot switch would send such an audio trigger at each
pedal press to transmit its exact timing and in parallel send the
MIDI command to give the trigger its meaning? And then hope that the
MIDI command arrives first...
It would require its own specific Audio/MIDI interface so the user
would not even notice that one audio channel is spent for this!
Did you plan or even do this or did it just come up here? :-)
>You are right, if you use something like a drum sound to trigger, it
>takes a handfull of samples. But even then, if you know roughly the
>waveform in advance, it should only create latency, not jitter.
yeah, this brings up the picture of a drummer that "records" a single
hit of one of his instruments as a reference and than starts playing
and the loop is automatically established between two (or 3...) hits
on that same instrument
>
>But I agree, there is not much need, I never felt that my triggers
>where too jittery...
>
>>I dont think so. the 20us go for a RTOS when its clear that
>>changing the task is needed. On the Powerbook there are loads of
>>threads running already and there must be some priority avaliation
>>that finially decides to care for the MIDI event, which then
>>resides in some buffer and so on... I have no idea how long it
>>takes, but I doubt you get to nano seconds.
>
>Its probably still some microseconds, I agree, but its interupt
>driven, that means it will interupt ongoing other tasks of the
>operating system to receive it, get a timestamp, and then switches
>back. But I am sure its much less than the duration of one Midi
>event, which is roughly 1 ms.
ok, the time stamp may be a lot more acurate than the execution.
Depending on what the MIDI event means, its delay can be corrected
with the timestamp (do you do that?) or not. For example the loop
lenght can be corrected with the time stamp of the two Record
commands, but we want the old loop to shut up immediately at
StartRecord, so the time stamp does not help, so the time from the
interrupt to its interpretation in the audio app plus the fade out
time counts, correct?
--
---> http://Matthias.Grob.org