15 Mar
2010
15 Mar
'10
11:02 a.m.
Hello guys!
I would like to ask any of the developers who might be interested to help a
musician out!
Original Kluppe developer seems very busy these days. And his programm lacks
two things I really need for my musical work.
I am ready to pay for the work. All the details below.
*1. Feature 1 - random play.*
When on Windows, I wrote a simple programm for myself, called Tape Loops. It
could play sounds either once or in a loop. The special function which I
added to it was "random play". What it did was allow you to define a period
of time in seconds. And the programm would trigger the sound randomly
somewhere within this period. So, if the period is 20 seconds, the programm
would play the sound either in 5 seconds, or in 10 or in 7 or in 20. When
the sounds stops playing, the timer is reset and the program once more
chooses a random moment to trigger the sound within the given period. By
changing the period the musician can make the sound get triggered more often
or less often.
The demo of how this program works can be viewed here:
http://www.louigiverona.ru/?page=projects&s=software&t=tapeloops&am…
It is a great feature - it helps a lot an ambient composer like myself and
is greatly useful for installations.
On Linux I have tried some programming, but even setting up JACK is very
difficult for me, I am absolutely not a strong desktop programmer. So
writing something like that from scratch on Linux is not realistic for me. I
tried Kluppe, which is the closest thing, it is a great piece of software,
but I studied the code for several days, tried some things, but apart from
changing the colors, I do not seem to be able to do anything meaningful.
So I would like to ask someone to do this job for me. To add a timer to a
kluppe looper and to allow this "random play" mode, where the musician can
put a looper into random play mode and define the period.
*2. Feature 2 - basic midi control.*
Looking through Kluppe code, I saw that a lot of midi is already done, but
it is not "attached" to the controls. I might be wrong and there may be more
work than it seems, but anyway. I would want to be able to assign midi
control to triggering loops, volume and panning - at least that. Otherwise,
Kluppe is very difficult to use in a live performance.
However, instead of proposing to allow to create separate controls for each
looper like they have in SooperLooper, I would advice (and actually, ask for
this feature to be implemented in such a manner) to instead go for the
Selected looper scheme. So that one would not need a dozen of knobs to
control things. There should be an ability to have one "Selected" looper.
Similar to what Dj Traktor Studio has. So you are binding midi not to a
definite looper, but to the Selected looper, and thus you would require only
two knobs (vol, pan) and three buttons (play/stop, Prev looper, Next
looper).
*3. Payment.*
I understand that all of the above might be not as simple as it seems to me
now. I would be willing to pay, as much as I can. I am able to pay through
PayPal. I do not know how much money is a normal pay for such work, but I
think something can be arranged. If I am not able to pay up instantly, I am
willing to pay for several months in a row to cover the necessary expenses.
I will also ask around on forums if someone will join me and also donate
some money - while my random play function is probably too specific and is
only something for me, midi control in Kluppe is something I believe many
people would want.
Thank you for your attention and I hope someone gets interested in the
request!
Louigi Verona.
http://www.louigiverona.ru/
15 Mar
15 Mar
11:13 a.m.
Hey,
I think that you would be a lot better off using a sampler (like Specimen..
:-)
and sending it MIDI commands when you want your sample triggered.
This MIDI event spitter could be programmed in: Python, C++ Java, Shell
Script, etc etc
Then connect your MIDI event spitter to the sampler, Voila... ;-)
Or did I misunderstand you request?
-Harry
Note that I dont discourage donating funds to the developers of Kluppe or
any GPL/ish softwares
11:24 a.m.
Kluppe has custom loop points, reverse sample, normalize and very nice JACK
handling. So I would want to use those features too.
Also, I do not know how to programm an event spitter. Unfortunately (
On Mon, Mar 15, 2010 at 5:13 PM, Harry Van Haaren <harryhaaren(a)gmail.com>wrote;wrote:
Hey,
I think that you would be a lot better off using a sampler (like Specimen..
:-)
and sending it MIDI commands when you want your sample triggered.
This MIDI event spitter could be programmed in: Python, C++ Java, Shell
Script, etc etc
Then connect your MIDI event spitter to the sampler, Voila... ;-)
Or did I misunderstand you request?
-Harry
Note that I dont discourage donating funds to the developers of Kluppe or
any GPL/ish softwares
12:50 p.m.
On Mon, 15 Mar 2010 17:24:03 +0300
Louigi Verona <louigi.verona(a)gmail.com> wrote:
Kluppe has custom loop points, reverse sample,
normalize and very
nice JACK handling. So I would want to use those features too.
Also, I do not know how to programm an event spitter. Unfortunately (
On Mon, Mar 15, 2010 at 5:13 PM, Harry Van Haaren
<harryhaaren(a)gmail.com>wrote;wrote:
> Hey,
>
> I think that you would be a lot better off using a sampler (like
> Specimen.. :-)
> and sending it MIDI commands when you want your sample triggered.
>
> This MIDI event spitter could be programmed in: Python, C++ Java,
> Shell Script, etc etc
>
> Then connect your MIDI event spitter to the sampler, Voila... ;-)
>
> Or did I misunderstand you request?
> -Harry
>
> Note that I dont discourage donating funds to the developers of
> Kluppe or any GPL/ish softwares
>
Hello, have you tried sooperlooper? It's well maintained and it's very
flexible. Don't know if you could achieve the random thing someway, but
surely midi is fully supported.
For the random thing, I agree with Harry that the easiest, and most
logical way to go is to find/write something that sends out MIDI
randomly; if you have to learn a language just for this I think
supercollider or puredata would be the best bet.
renato
1:54 p.m.
Hey!
Yes, I've tried SooperLooper. Unfortunately, it has the limit on the size of
the samples
and samples which exceed the size of 10 Mb do not get loaded. It has several
other things
which do not suit my workflow. So Kluppe is my best choice for a reason.
As for learning a language - I am a musician, not a programmer. This is
exactly why I posted this
request - because I do not feel that I am able to pursue programming to make
several changes to the
already great piece of software.
On Mon, Mar 15, 2010 at 6:52 PM, Renato <rennabh(a)gmail.com> wrote:
On Mon, 15 Mar 2010 17:24:03 +0300
Louigi Verona <louigi.verona(a)gmail.com> wrote:
Kluppe has
Hello, have you tried sooperlooper? It's well maintained and it's very
flexible. Don't know if you could achieve the random thing someway, but
surely midi is fully supported.
For the random thing, I agree with Harry that the easiest, and most
logical way to go is to find/write something that sends out MIDI
randomly; if you have to learn a language just for this I think
supercollider or puredata would be the best bet.
renato
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
20 Jul
20 Jul
1:06 a.m.
On Mon, Mar 15, 2010 at 6:02 PM, Louigi Verona <louigi.verona(a)gmail.com>wrote;wrote:
Hello guys!
I would like to ask any of the developers who might be interested to help a
musician out!
Original Kluppe developer seems very busy these days. And his programm
lacks two things I really need for my musical work.
I am ready to pay for the work. All the details below.
*1. Feature 1 - random play.*
When on Windows, I wrote a simple programm for myself, called Tape Loops.
It could play sounds either once or in a loop. The special function which I
added to it was "random play". What it did was allow you to define a period
of time in seconds. And the programm would trigger the sound randomly
somewhere within this period. So, if the period is 20 seconds, the programm
would play the sound either in 5 seconds, or in 10 or in 7 or in 20. When
the sounds stops playing, the timer is reset and the program once more
chooses a random moment to trigger the sound within the given period. By
changing the period the musician can make the sound get triggered more often
or less often.
The demo of how this program works can be viewed here:
http://www.louigiverona.ru/?page=projects&s=software&t=tapeloops&am…
It is a great feature - it helps a lot an ambient composer like myself and
is greatly useful for installations.
On Linux I have tried some programming, but even setting up JACK is very
difficult for me, I am absolutely not a strong desktop programmer. So
writing something like that from scratch on Linux is not realistic for me. I
tried Kluppe, which is the closest thing, it is a great piece of software,
but I studied the code for several days, tried some things, but apart from
changing the colors, I do not seem to be able to do anything meaningful.
So I would like to ask someone to do this job for me. To add a timer to a
kluppe looper and to allow this "random play" mode, where the musician can
put a looper into random play mode and define the period.
*2. Feature 2 - basic midi control.*
Looking through Kluppe code, I saw that a lot of midi is already done, but
it is not "attached" to the controls. I might be wrong and there may be more
work than it seems, but anyway. I would want to be able to assign midi
control to triggering loops, volume and panning - at least that. Otherwise,
Kluppe is very difficult to use in a live performance.
However, instead of proposing to allow to create separate controls for each
looper like they have in SooperLooper, I would advice (and actually, ask for
this feature to be implemented in such a manner) to instead go for the
Selected looper scheme. So that one would not need a dozen of knobs to
control things. There should be an ability to have one "Selected" looper.
Similar to what Dj Traktor Studio has. So you are binding midi not to a
definite looper, but to the Selected looper, and thus you would require only
two knobs (vol, pan) and three buttons (play/stop, Prev looper, Next
looper).
*3. Payment.*
I understand that all of the above might be not as simple as it seems to me
now. I would be willing to pay, as much as I can. I am able to pay through
PayPal. I do not know how much money is a normal pay for such work, but I
think something can be arranged. If I am not able to pay up instantly, I am
willing to pay for several months in a row to cover the necessary expenses.
I will also ask around on forums if someone will join me and also donate
some money - while my random play function is probably too specific and is
only something for me, midi control in Kluppe is something I believe many
people would want.
Thank you for your attention and I hope someone gets interested in the
request!
Louigi Verona.
http://www.louigiverona.ru/
Hey guys!
Some time ago I have asked someone to look into Kluppe and add a couple of
features.
My request was not ignored and Patrick Shirkey was kind enough to volunteer
to try to help.
However, he came upon a difficulty and that is - *how do you set up an
asynchronous timer in C?*
It stopped right there. I was wondering if anyone could help us with that
matter?
Cheers!
--
Louigi Verona
http://www.louigiverona.ru/
1:45 a.m.
On 07/20/2010 01:06 AM, Louigi Verona wrote:
Hey guys!
Some time ago I have asked someone to look into Kluppe and add a couple of
features.
My request was not ignored and Patrick Shirkey was kind enough to volunteer
to try to help.
However, he came upon a difficulty and that is - *how do you set up an
asynchronous timer in C?*
It depends what you need that timer for.
In gtk there's a g_timeout_add(). easy to use.
To writing your own:
`apropos pthread` and more specifically `man pthread_create`.
usleep() sleeps at least, and select() sleeps at most a certain period
of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
has examples of both.
For [more] accurate timing: RTC or HPET. Example code comes
with the kernel:
linux-2.6/Documentation/rtc.txt
linux-2.6/Documentation/hpet.txt
There's a couple of other options fi. if you want to sync
hardware-devices using IRQs.. and the jack_process_callback is also very
good timer :)
It stopped right there. I was wondering if anyone
could help us with that
matter?
Cheers!
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
9:16 a.m.
On 07/20/2010 09:45 AM, Robin Gareus wrote:
--
Patrick Shirkey
Boost Hardware Ltd
On 07/20/2010 01:06 AM, Louigi Verona wrote:
The timer is needed to countdown the period between stopping and
restarting the loop. The methods I have tried all halt the playback on a
single frame and the ui also becomes unresponsive while the timer is in
process.
All I would like to do is pass a zero byte to the audio signal handling
code while the timer is in progress. The rest of the interface should
stay active.
Hey guys!
Some time ago I have asked someone to look into Kluppe and add a couple of
features.
My request was not ignored and Patrick Shirkey was kind enough to volunteer
to try to help.
However, he came upon a difficulty and that is - *how do you set up an
asynchronous timer in C?*
It depends what you need that timer for.
In gtk there's a g_timeout_add(). easy to use.
Will check that one. Might do the trick.
To writing your own:
`apropos pthread` and more specifically `man pthread_create`.
Otherwise will look into this.
usleep() sleeps at least, and select() sleeps at most
a certain period
of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
has examples of both.
Tried both of these options and they cause the app to pause with an
annoying buzz while the timer is in effect.
For [more] accurate timing: RTC or HPET. Example code
comes
with the kernel:
linux-2.6/Documentation/rtc.txt
linux-2.6/Documentation/hpet.txt
There's a couple of other options fi. if you want to sync
hardware-devices using IRQs.. and the jack_process_callback is also very
good timer :)
Not required for this task.
It stopped
right there. I was wondering if anyone could help us with that
matter?
Cheers!
10:54 a.m.
On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
Don't forget to read the note:
http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#…
It's not very accurate but Example code is easy to come by.
In that case you should get x-runs. Otherwise it may well be that you
simply don't zero the audio-output. It's hard to tell what's going on
w/o seeing the source.
As for the GUI being unresponsive: The key part is to use usleep() in a
separate thread.
Here are two simple examples using pthread to do so:
http://rg42.org/_media/wiki/async-timer.c # use a byte to indicate
http://rg42.org/_media/wiki/async-timer2.c # use a MUTEX
You may want to elaborate on the usleep() call (fi. check for EINTR -
see the freeJ source).
ciao
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
On 07/20/2010 09:45 AM, Robin Gareus wrote:
That sounds like it needs to be be quite accurate, or not?
On 07/20/2010 01:06 AM, Louigi Verona wrote:
The timer is needed to countdown the period between stopping and
restarting the loop. The methods I have tried all halt the playback on a
single frame and the ui also becomes unresponsive while the timer is in
process.
Hey guys!
Some time ago I have asked someone to look into Kluppe and add a
couple of
features.
My request was not ignored and Patrick Shirkey was kind enough to
volunteer
to try to help.
However, he came upon a difficulty and that is - *how do you set up an
asynchronous timer in C?*
It depends what you need that timer for.
All I would like to do is pass a zero byte to the
audio signal handling
code while the timer is in progress. The rest of the interface should
stay active.
A simple approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
In gtk
there's a g_timeout_add(). easy to use.
Will check that one. Might do the trick. To writing
your own:
`apropos pthread` and more specifically `man pthread_create`.
Otherwise will look into this.
usleep() sleeps at least, and select() sleeps at
most a certain period
of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
has examples of both.
Tried both of these options and they cause the app to pause with an
annoying buzz while the timer is in effect. For [more]
accurate timing: RTC or HPET. Example code comes
with the kernel:
linux-2.6/Documentation/rtc.txt
linux-2.6/Documentation/hpet.txt
There's a couple of other options fi. if you want to sync
hardware-devices using IRQs.. and the jack_process_callback is also very
good timer :)
Not required for this task.
>> It stopped right there. I was wondering if anyone could help us with
>> that
>> matter?
>>
>>
>> Cheers!
>>
>>
1:48 p.m.
On 07/20/2010 06:54 PM, Robin Gareus wrote:
The problem is how to set a counter that doesn't block the rest of the
app while it is in process.
Don't forget to read the note:
http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#…
It's not very accurate but Example code is easy to come by.
In that case you should get x-runs. Otherwise it may well be that you
simply don't zero the audio-output. It's hard to tell what's going on
w/o seeing the source.
I am not seeing xruns.
On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
It just needs to work ;-)
On 07/20/2010 09:45 AM, Robin Gareus wrote:
That sounds like it needs to be be quite accurate, or not?
On 07/20/2010 01:06 AM, Louigi Verona wrote:
The timer is needed to countdown the period between stopping and
restarting the loop. The methods I have tried all halt the playback on a
single frame and the ui also becomes unresponsive while the timer is in
process.
Hey guys!
Some time ago I have asked someone to look into Kluppe and add a
couple of
features.
My request was not ignored and Patrick Shirkey was kind enough to
volunteer
to try to help.
However, he came upon a difficulty and that is - *how do you set up an
asynchronous timer in C?*
It depends what you need that timer for.
All I would
like to do is pass a zero byte to the audio signal handling
code while the timer is in progress. The rest of the interface should
stay active.
A simple approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
In gtk there's a g_timeout_add(). easy to use.
Will check that one. Might do the trick.
To
writing your own:
`apropos pthread` and more specifically `man pthread_create`.
Otherwise will look into this.
usleep() sleeps at least, and select() sleeps at
most a certain period
of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
has examples of both.
Tried both of these options and they cause the app to pause with an
annoying buzz while the timer is in effect.
As for the GUI being unresponsive: The key part is to
use usleep() in a
separate thread.
Here are two simple examples using pthread to do so:
http://rg42.org/_media/wiki/async-timer.c # use a byte to indicate
http://rg42.org/_media/wiki/async-timer2.c # use a MUTEX
Thanks for those. They are pretty much what I was looking for. Don't
know why but that info was really hard for me to locate via google when
I last looked.
If you have the inclination you can see where I got to with this code
because I have uploaded a new version here:
http://djcj.org/code/kluppe-0.6.14-playbackdelay-v2.tar.bz2
The core mod is in src/common/looperdata.c:1355
Basic operation is to create a new track, import a buffer file, load the
buffer, set the playback delay to > 0 and press play. When it gets to
the end of the loop range it will stop for the number of seconds in the
playback delay spinbox.
It's now at least partially working. Needs some finetuning with multiple
tracks but at least that annoying buzz has gone and the ui stays
responsive. I'll spend some more time on it in the next few days no
doubt. But if anyone else feels like giving it a tweak then be my guest.
I'm sure Louigi will be keen to test out any improvements.
Funny but it took me longer tonight to get jack working properly than it
did to add that code and make it do something useful :-/
Here's what I did in case anyone else comes across it at a later date:
+++++++++++++++
if(data->playbackdelay > 0){
printf ("in lcss: set playbackdelay =
%f\n",data->playbackdelay);
if (async_timeout == 0){
async_timeout = data->playbackdelay;
pthread_mutex_init(&timer_lock, NULL);
pthread_mutex_lock(&timer_lock);
rv = pthread_create(&thread_id_tt, NULL,
timer_thread, &async_timeout);
vol = data->vol;
looperdata_set_vol(data,0);
if (rv) {
printf("thread creation failed.\n");
// break;
}
}
// test if the timer is still running:
if (!pthread_mutex_trylock(&timer_lock)) {
pthread_mutex_unlock(&timer_lock);
// timer finished
data->playindex += data->loopstart - data->loopend;
looperdata_set_vol(data,vol);
// clean-up
pthread_join(thread_id_tt, NULL);
pthread_mutex_destroy(&timer_lock);
async_timeout = 0;
// break;
}
}
+++++++++++++=
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
1:51 p.m.
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
i believe that robin's suggestion is the correct one. you don't want
to attempt audio timing using the system clock unless you have a
DLL/PLL that relates audio time to system time (and you don't).
decisions about what to do as time progresses need to be made in the
process() callback tree, not in the GUI or some other thread.
so just countdown some number of samples, and then resume playing, as
robin suggested. it won't block anything, anywhere.
A simple
approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
The problem is how to set a counter that doesn't block the rest of the app
while it is in process.
2:17 p.m.
On 07/20/2010 01:48 PM, Patrick Shirkey wrote:
The problem is how to set a counter that doesn't block the rest of the
app while it is in process.
Outline:
global:
static long int mycounter = 0;
main-thread:
if (need_to pause) mycounter = time_to_pause * sample_rate;
audio-thread:
if (mycounter > 0) { mycounter -= samples_processed_here; }
if (mycounter > 0) mute;
else play;
The 'mycounter' variable does not need to be global. It can be part of
the track struct or class eg. track->mutecounter.
..and eventually you implement it to be sample-accurate (the above is
just an outline).
Cheers!
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
On 07/20/2010 06:54 PM, Robin Gareus wrote:
Are you really sure? :-p
On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
It just needs to work ;-) On 07/20/2010 09:45 AM, Robin Gareus wrote:
That sounds like it needs to be be quite accurate, or not?
On 07/20/2010 01:06 AM, Louigi Verona wrote:
> Hey guys!
>
> Some time ago I have asked someone to look into Kluppe and add a
> couple of
> features.
> My request was not ignored and Patrick Shirkey was kind enough to
> volunteer
> to try to help.
>
> However, he came upon a difficulty and that is - *how do you set up an
> asynchronous timer in C?*
>
>
It depends what you need that timer for.
The timer is needed to countdown the period between stopping and
restarting the loop. The methods I have tried all halt the playback on a
single frame and the ui also becomes unresponsive while the timer is in
process.
All I would like to do is pass a zero byte to the
audio signal handling
code while the timer is in progress. The rest of the interface should
stay active.
A simple approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
2:46 p.m.
On 07/20/2010 09:51 PM, Paul Davis wrote:
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
i believe that robin's suggestion is the correct one. you don't
want
to attempt audio timing using the system clock unless you have a
DLL/PLL that relates audio time to system time (and you don't).
decisions about what to do as time progresses need to be made in the
process() callback tree, not in the GUI or some other thread.
so just countdown some number of samples, and then resume playing, as
robin suggested. it won't block anything, anywhere.
I don't have any problem with counting down using the audio clock but
how do I translate that into seconds/milliseconds set in the ui?
At the moment the timer counts in seconds using this function
void *timer_thread(void *arg) {
int how_long = *((int*) arg);
sleep(how_long);
pthread_mutex_unlock(&timer_lock);
return NULL;
}
While it is counting I set the volume for the per track playback buffer
to zero. I also need to stop the playhead from moving but that is a
seperate issue.
Ideally the timer should count in milliseconds which I guess is handled
by changing the call to sleep to select instead?
ex.
void *timer_thread(void *arg) {
int how_long = *((int*) arg);
pause.tv_sec = how_long;
pause.tv_usec = 0;
(void) select(0, 0, 0, 0, &pause);
pthread_mutex_unlock(&timer_lock);
return NULL;
}
I'm not sure how to do that with audio samples instead. Happy to make it
work that way though if it is the best approach.
--
Patrick Shirkey
Boost Hardware Ltd
A simple
approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
The problem is how to set a counter that doesn't block the rest of the
app
while it is in process.
3:08 p.m.
On 07/20/2010 02:46 PM, Patrick Shirkey wrote:
On 07/20/2010 09:51 PM, Paul Davis wrote:
see my other email.
You must be tired tonight :) Just multiply it by the sample-rate..
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
i believe that robin's suggestion is the correct one. you don't
want
to attempt audio timing using the system clock unless you have a
DLL/PLL that relates audio time to system time (and you don't).
decisions about what to do as time progresses need to be made in the
process() callback tree, not in the GUI or some other thread.
so just countdown some number of samples, and then resume playing, as
robin suggested. it won't block anything, anywhere.
I don't have any problem with counting down using the audio clock but
how do I translate that into seconds/milliseconds set in the ui? A simple
approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.
The problem is how to set a counter that doesn't block the rest of
the app
while it is in process.
At the moment the timer counts in seconds using this
function
void *timer_thread(void *arg) {
int how_long = *((int*) arg);
sleep(how_long);
pthread_mutex_unlock(&timer_lock);
return NULL;
}
While it is counting I set the volume for the per track playback buffer
to zero. I also need to stop the playhead from moving but that is a
seperate issue.
Ideally the timer should count in milliseconds which I guess is handled
by changing the call to sleep to select instead?
ex.
void *timer_thread(void *arg) {
int how_long = *((int*) arg);
pause.tv_sec = how_long;
pause.tv_usec = 0;
(void) select(0, 0, 0, 0, &pause);
pthread_mutex_unlock(&timer_lock);
return NULL;
}
Either that, or use usleep(microseconds).
I'm not sure how to do that with audio samples
instead. Happy to make it
work that way though if it is the best approach.
it is.
best,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
3:09 p.m.
On 07/20/2010 11:08 PM, Paul Davis wrote:
On Tue, Jul 20, 2010 at 8:46 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Ok, I spotted that with Robins last email too. I'll look into it.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
I don't have any problem with counting down
using the audio clock but how do
I translate that into seconds/milliseconds set in the ui?
divide or multiply by the sample rate?
27 Jul
27 Jul
5:08 p.m.
Thanks for those. They are pretty much what I was looking for. Don't know
why but that info was really hard for me to locate via google when I last
looked.
If you have the inclination you can see where I got to with this code
because I have uploaded a new version here:
http://djcj.org/code/kluppe-0.6.14-playbackdelay-v2.tar.bz2
The core mod is in src/common/looperdata.c:1355
Basic operation is to create a new track, import a buffer file, load the
buffer, set the playback delay to > 0 and press play. When it gets to the
end of the loop range it will stop for the number of seconds in the playback
delay spinbox.
It's now at least partially working. Needs some finetuning with multiple
tracks but at least that annoying buzz has gone and the ui stays responsive.
I'll spend some more time on it in the next few days no doubt. But if anyone
else feels like giving it a tweak then be my guest. I'm sure Louigi will be
keen to test out any improvements.
Hey Patrick!
Just compiled this latest version. Unfortunately, I couldn't really get this
to work yet.
First off, I still get the buzz when the delay does work. If I route audio
from individual looper outs, the buzz is there too if you just hit Pause.
Second, the delay function worked only a couple of times - the rest of the
time changing its value from 0 to whatever did not create any delay. Times
that it did work it paused all the loops with a buzz. One time kluppe
crashed when the playhead reached the end of the loop, but I could not
reproduce it later.
By the way, is it possible to delay a custom loop? I mean, is delay applied
only to the end of the file or when the end loop point is reached?
Anyway, always ready to test the new version!
Cheers!
L.V.
5029
days inactive
5163
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
6 participants
participants (6)
-
Harry Van Haaren -
Louigi Verona -
Patrick Shirkey -
Paul Davis -
Renato -
Robin Gareus