Re: [LAD] Can someone add 2 features to Kluppe?
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 11:08 PM, Paul Davis wrote: On Tue, Jul 20, 2010 at 8:46 AM, Patrick Shirkey wrote: 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? Ok, I spotted that with Robins last email too. I'll look into it. Cheers. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 02:46 PM, Patrick Shirkey wrote:
> On 07/20/2010 09:51 PM, Paul Davis wrote:
>> On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
>> wrote:
>>
>>
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.
>>>
>> 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?
see my other email.
You must be tired tonight :) Just multiply it by the sample-rate..
> 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: ro...@gareus.org
site: http://gareus.org/ chat: xmpp:rgar...@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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On Tue, Jul 20, 2010 at 8:46 AM, Patrick Shirkey wrote: > 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? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 09:51 PM, Paul Davis wrote:
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
wrote:
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.
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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 01:48 PM, Patrick Shirkey wrote:
> On 07/20/2010 06:54 PM, Robin Gareus wrote:
>> On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
>>
>>> On 07/20/2010 09:45 AM, Robin Gareus wrote:
>>>
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.
>>>
>> That sounds like it needs to be be quite accurate, or not?
>>
>>
>
> It just needs to work ;-)
Are you really sure? :-p
>>> 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.
>>
>>
>
> 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: ro...@gareus.org
site: http://gareus.org/ chat: xmpp:rgar...@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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey wrote: >> 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. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 06:54 PM, Robin Gareus wrote:
On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
On 07/20/2010 09:45 AM, Robin Gareus wrote:
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.
That sounds like it needs to be be quite accurate, or not?
It just needs to work ;-)
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.
The problem is how to set a counter that doesn't block the rest of the
app while it is in process.
In gtk there's a g_timeout_add(). easy to use.
Will check that one. Might do the trick.
Don't forget to read the note:
http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-timeout-add
It's not very accurate but Example code is easy to come by.
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.
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.
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;
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 09:17 AM, Patrick Shirkey wrote: > On 07/20/2010 09:45 AM, Robin Gareus wrote: >> 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. That sounds like it needs to be be quite accurate, or not? > 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. Don't forget to read the note: http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-timeout-add It's not very accurate but Example code is easy to come by. >> 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. 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). >> 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! >>> >>> ciao robin -- Robin Gareus mail: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On 07/20/2010 09:45 AM, Robin Gareus wrote: 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. 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! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
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: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On Mon, Mar 15, 2010 at 6:02 PM, Louigi Verona 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&a=tapeloops_tapeloops1 > > 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe? (olivier)
I will check out the latest version of SL, but the problem I have with SL is that 1. It doesn't load samples over 10Mb 2. It never displays a file name of a loaded loop, so as the number of open loops grows, you forget which one is which 3. SL was done with very different usage in mind. That shows in almost every feature it has, they way it is done. Also, what's simple programming for you, the devs, is a very difficult puzzle for a non-programmer. I just learned to compile from source properly ;) Cheers! On Tue, Mar 16, 2010 at 12:45 AM, Olivier wrote: > > 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. >> > > sooperlooper allready has this feature, look for the latest releases. > > simple MIDI programming with bash/mididings, pd or csound could easily add > the "random" feature to it > > olivier > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe? (olivier)
> 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. > sooperlooper allready has this feature, look for the latest releases. simple MIDI programming with bash/mididings, pd or csound could easily add the "random" feature to it olivier ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
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 wrote: > On Mon, 15 Mar 2010 17:24:03 +0300 > Louigi Verona 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
On Mon, 15 Mar 2010 17:24:03 +0300 Louigi Verona 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 > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
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 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 > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Can someone add 2 features to Kluppe?
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
