[audio] Regarding Latency And Looping
scorelessmusic
Member Posts: 565
Just thought that I should document my findings as I continue to work with GS on music applications that have critical need for proper triggering and precision timing.
I am branching my findings into two different application builds now based on my most recent discovery.
1. LATENCY (the delay between a 'live' trigger a actual sound played)
Since I am essentially building a music instrument, the application must feel responsive to a musician. In the physical world, we are used to instant triggers because that's just the way things work. If I hit a drum, I expect the sound it makes to be produced instantly (and the time it takes to travel to me ears, negligible)
On a software instrument, this translates as the time between my fingers triggering by any means (in CHORDiUM's case, a key pressed on the computer keyboard) and the time the sound is heard.
For most part, the latency is negligible for a simple trigger->sound. However, the problem comes when you have to program in more complex routines for the 'live' trigger. Like making the sound play multiple times when pressing the same trigger repeatedly. Ensuring the sound continues playing even after the finger leaves the trigger. Ensuring the sound cuts off automatically when another trigger is hit.
Based on the way GS handles its user-generated scripts/code now, I have to admit that it's not looking good for people hoping to replicate the more complex nature of live music instrument triggering. At one point, I even had to artificially insert a delay just so that certain processes are handled properly.
CURRENT CONCLUSION: GS is probably not the best RAD kit for software music instruments requiring complex 'live' triggers (eg. a software piano)
2. LOOPING (when triggers are predetermined and repeat according to timing)
The good news is that if your triggers do not require 'live' response and can be programmed for looping, it is possible to engineer a pretty reliable timer routine to handle accurate triggering of such sounds. This simply requires proper discipline in using the timer function in GS.
CURRENT CONCLUSION: GS should perform well for sequencing softwares like a Rhythm Composer (eg. drum machine that loops)
----------------
Going forward, if I get any brilliant ideas for 'live' triggering, I'll revisit GS for CHORDiUM. Until then, I'm moving CHORDiUM to a different RAD kit for building.
I've started a new app called NeuMET1K (pronounced "pneumatic" ^_^) which will be a Rhythm Composer as mentioned earlier. I'll be using GS and pushing the limits of the timer function to see if I can make an accurate looping instrument.
I am branching my findings into two different application builds now based on my most recent discovery.
1. LATENCY (the delay between a 'live' trigger a actual sound played)
Since I am essentially building a music instrument, the application must feel responsive to a musician. In the physical world, we are used to instant triggers because that's just the way things work. If I hit a drum, I expect the sound it makes to be produced instantly (and the time it takes to travel to me ears, negligible)
On a software instrument, this translates as the time between my fingers triggering by any means (in CHORDiUM's case, a key pressed on the computer keyboard) and the time the sound is heard.
For most part, the latency is negligible for a simple trigger->sound. However, the problem comes when you have to program in more complex routines for the 'live' trigger. Like making the sound play multiple times when pressing the same trigger repeatedly. Ensuring the sound continues playing even after the finger leaves the trigger. Ensuring the sound cuts off automatically when another trigger is hit.
Based on the way GS handles its user-generated scripts/code now, I have to admit that it's not looking good for people hoping to replicate the more complex nature of live music instrument triggering. At one point, I even had to artificially insert a delay just so that certain processes are handled properly.
CURRENT CONCLUSION: GS is probably not the best RAD kit for software music instruments requiring complex 'live' triggers (eg. a software piano)
2. LOOPING (when triggers are predetermined and repeat according to timing)
The good news is that if your triggers do not require 'live' response and can be programmed for looping, it is possible to engineer a pretty reliable timer routine to handle accurate triggering of such sounds. This simply requires proper discipline in using the timer function in GS.
CURRENT CONCLUSION: GS should perform well for sequencing softwares like a Rhythm Composer (eg. drum machine that loops)
----------------
Going forward, if I get any brilliant ideas for 'live' triggering, I'll revisit GS for CHORDiUM. Until then, I'm moving CHORDiUM to a different RAD kit for building.
I've started a new app called NeuMET1K (pronounced "pneumatic" ^_^) which will be a Rhythm Composer as mentioned earlier. I'll be using GS and pushing the limits of the timer function to see if I can make an accurate looping instrument.
Comments
Cheers,
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
When I was 12, it was just a dream that hundreds and thousands would use software that I create. Now I'm living it.
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Glad to be (soon to be! Waiting for Apple review) on it
I love my drum machines ;-) and music gadgets.
Of course, with the right software, iOS device can be some of the best musical gadgets!
re: Music / Drum Machines on GS
Yes, the timing isn't quite "musically perfect" -
After Radarhead (a successful "proof of concept"!)
I'm making more nonstandard music apps, and could hear slight drifts in beat timing.
(see also my other post - the "Pitch Glitch"!)
C'est la vie, I guess? It's "close enough".
I don't think there are any other iPad dev kits I could deal with,
being "more an artist than programmer". Objective C might seem... objectionable!
If you're REALLY worried about timing, there are such things as Max for Ableton Live and Reaktor - on iOS - Jasuto Modular? but (I think?) you can't sell what you make,
and there is no runtime for iOS. (...yet! Can you imagine, Max MSP on iPad? OMG!)
That said, let us respectfully* ask for more detailed audio (and video out!) options on GS.
(such as playing a sample from a point other than the start! (reversing it?) and ending earlier than the end, on "sound effects" and "music".)
Among many things, I'm a pro music / projection art performer, and gear / app reviewer,
and I can see many creative possibilities with GS!
*be nice to the programmers! Their work is SO MUCH harder than it looks.