Re: Real-time category

[Matthias Grob <matigrob@terra.com.br>]

>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