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] [LAU] New modular synthesis library w/ ruby bindings
The Key object has a root parameter; that's why middle c is 0. You can set 0 to be anything you want, just use s.key.root = #. To set middle C as 60, just do s.key.root = s.key.note2freq(-60). I'm also in favor of standards, but as my notes can cover a range bigger than 0-127, and take fractional values, I'm not sure MIDI is appropriate. I'm unaware of any standards that would fit my requirements, but if someone else is, please let me know. It might be a good idea to set a default root such that 60 = middle C; I'll think about this. But regardless, 0 won't represent the same note everywhere. Another complication is that an octave doesn't always have 12 tones. You can set the tuning for harmonic major/minor (7 tones), or anything else you want. I seem to remember there being some interesting Indian scales that have 15 or 16 notes per octave. One thing this means is that note 0 : note 1 :: note 1 : note 2 doesn't always hold. But since the default is equal temperament, I will consider setting the default root such that those who are used to MIDI will be least surprised. Though that would make the other functionality of Key more surprising, so I'm not sure yet. One of the design goals with this entire system is that physical constraints (your sound card's sample rate and the accuracy and range of IEEE floating-point arithmetic) should be the only constraints keeping you from being as exact as you want to be. In many cases this means that the MIDI standard must be discarded. But being able to communicate with other stuff (including a MIDI-wired brain :-) is also important. At some point I would like to create a module that translates midi key on/off controls to the system I have set up here, but that's nontrivial given the fact that controls (likely) come from a standard keyboard, which has a certain physicality that annoyingly conflicts with the concept of differing numbers of notes per octave. Evan On Mon, Jul 19, 2010 at 12:13 PM, Harry Van Haaren harryhaa...@gmail.com wrote: On Mon, Jul 19, 2010 at 8:06 PM, Bernardo Barros bernardobarr...@gmail.com wrote: At least for me it would be easier to think as c = 0 c = 0 c' = 12 c, = -12 c'' = 24 c,, = -24 because most of the notes in a regular score is mostly like to happen in the middle and things looks simpler that way. UNLESS you're already familiar with all kind of notes with MIDI number notation. Hey, Yes I was referring to the MIDI standard there.. Should have mentioned that.. There's no rule telling you you should do it differently, I'm expressing my opinion that for me it would seem more logical to have middle C at 60. -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] May I asked something OT?
On Mon, 2010-07-19 at 20:17 +0100, Folderol wrote: On Mon, 19 Jul 2010 14:04:24 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Mon, 2010-07-19 at 01:30 -0400, Tim E. Real wrote: On July 18, 2010 03:57:06 pm Ralf Mardorf wrote: A lot of kids wish to have a kill switch for their guitars. A kill switch is a short circuit, to 'stop' the audio signal. I'm not fine with this solution, but the kids argue, that e.g. an interruption does cause unwanted noise, especially for over drive sounds. IMO even using opto-electronics won't solve the issue, because the noise of the transistor overdrive effect still would be hearable, while for a short circuit there is silence. Has anybody an idea to solve this without a short circuit? I'm really not a fan of short circuits. Note, it's not possible to do an interrupt all the times behind the latest noise generator and even an interrupt could cause noise itself, while a short circuit indeed is a good way to cancel sound. If you play a Gibson you can set the neck pickup volume to zero and the bridge pickup volume to full and then toggle the pickup switch, rapidly if desired, like Eddie van Halen on You Really Got Me. Tim. Yes, but this could cause noise by the switch or by effects, e.g. the sustainer. I guess the kids prevent any noise by a short circuit, perhaps even the sustainer then will be 'killed', if so, OTOH I guess this won't be good for the effects and amps. As some people mentioned before, it would be better to use some kind of gate at the end of the effect chain. I really wonder what happens to e.g. a sustainer or to the pre-amp of the guitar's amp when doing a short circuit. I guess because of a short circuit there really will be silence. I also wonder if just interrupting would cause that annoying noise, believing the hype, it should cause annoying noise. Btw. for all this Japan avant-garde a Gibson switch or a foot switch isn't good, they do need a momentary switch. Because it's really used by kids, I wonder how old the equipment would become. A short-circuit protection won't protect against impulses, OTOH just interrupting might also cause impulses. Thank you all :) Ralf I'm not really clear on what your objection is to shorting the guitar pickups. I've never heard of it causing any problem. There is a remarkably effective click-free way of muting a guitar. The original involved a light-dependent-resistor and a filament bulb, but these days you'd be better off using an LED as the light source. The L.D.R. (typically ORP12) is in a light proof box with a hole in line with the LED. The LDR shunts the guitar output. When 'dark' it has a typical value of 5 Meg, and has no noticeable effect. When 'light' it is typically 100 Ohm and effectively shorts out the pickups. However the trick is NOT to switch the LED off and on, but to keep it on all the time and arrange the pedal/switch so it slides an opaque vane or shutter between the LED and the L.D.R. These switches can be made *extremely* robust and never wear out or become noisy. A variant of this was used as a swell pedal in the original GEM portable organ of the middle 1960s - I know. I had one :) I never opened a Morley pedal, but I guess this is the way they use opto. But it's solved, I did error in reasoning: Forwarded Message From: Gordon JC Pearce gordon...@gjcp.net To: linux-audio-dev@lists.linuxaudio.org Subject: Re: [LAD] May I asked something OT? Date: Mon, 19 Jul 2010 20:04:28 +0100 On Mon, 2010-07-19 at 14:45 +0200, Ralf Mardorf wrote: http://www.instructables.com/image/FC6ZZ0XF8JUW8E8/What-is-a-killswitch.jpg This is what I call short circuit. It won't harm a pre-amp doing it by a potentiometer, but I wonder if doing it fast, again and again by a switch won't cause impulses, when the short circuit will be released again? Perhaps I do error in reasoning and it's quite save. Yes, it's entirely safe. At that stage you've got a few tens of millivolts of signal at best, across about a 1k impedance source. Gordon MM0YEQ ___ 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 Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey pshir...@boosthardware.com 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 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 07/20/2010 09:51 PM, Paul Davis wrote:
On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
pshir...@boosthardware.com 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 Tue, Jul 20, 2010 at 8:46 AM, Patrick Shirkey pshir...@boosthardware.com 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 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
pshir...@boosthardware.com 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 07/20/2010 11:08 PM, Paul Davis wrote: On Tue, Jul 20, 2010 at 8:46 AM, Patrick Shirkey pshir...@boosthardware.com 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] MVerb for LADSPA/LV2/???
On Wed, Jun 9, 2010 at 9:19 AM, Brett McCoy idragos...@gmail.com wrote: Both a plugin version and a standalone app would be awesome! On Wed, Jun 9, 2010 at 9:16 AM, Louigi Verona louigi.ver...@gmail.com wrote: A plugin would be nice! On Wed, Jun 9, 2010 at 5:14 PM, Dave Phillips dlphill...@woh.rr.com wrote: Greetings, Martin Eastwood has posted the code for his MVerb: http://martineastwood.com/ Open-source, GPL3'd free software. Maybe someone could whip up a plugin or standalone app from this code ? PS: If you download the zipfile note that it does not include a top-level directory, i.e. it'll dump its contents into the current directory. Best, dp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- 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 -- In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world. -- Jelaleddin Rumi ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Just a note: his website has been updated with an LADSPA version. Jeremy ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] El-Cheapo software-only equivalent
Hi all, i'm new to this list. I'd like to ask some advice about a small multitrack recorder program i wrote, and have been using for some time. Basically, what it does is to: - simultaneously capture sound from several consumer-grade soundcards. - use libsamplerate to stretch the audio streams, re-syncing them to the one chosen as master. The stretch ratio is continuously re-calculated to make the overall frame count of the stretched stream match the overall frame count of the master. - write the corrected streams plus the master stream to parallel .wav files using libsndfile. The purpose is the same as the quite famous El-Cheapo Howto ( http://quicktoots.linuxaudio.org/toots/el-cheapo ), just with no soldering involved :-) Of course, i know the solution is far from perfect, but i use it to record some friends of mine who play in a blues/punk band, and the result is not that bad. Now, the question is: do you think this piece of code can be of any interest for someone out there? Do you think i should i publish it on an open source repository ? Or maybe there's already some other software i'm not aware of, that does the same thing? thanks for your patience, please excuse my bad english. bye alberto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] El-Cheapo software-only equivalent
On 07/21/2010 10:24 AM, rom wrote: Hi all, i'm new to this list. I'd like to ask some advice about a small multitrack recorder program i wrote, and have been using for some time. Basically, what it does is to: - simultaneously capture sound from several consumer-grade soundcards. - use libsamplerate to stretch the audio streams, re-syncing them to the one chosen as master. The stretch ratio is continuously re-calculated to make the overall frame count of the stretched stream match the overall frame count of the master. - write the corrected streams plus the master stream to parallel .wav files using libsndfile. The purpose is the same as the quite famous El-Cheapo Howto ( http://quicktoots.linuxaudio.org/toots/el-cheapo ), just with no soldering involved :-) Of course, i know the solution is far from perfect, but i use it to record some friends of mine who play in a blues/punk band, and the result is not that bad. Now, the question is: do you think this piece of code can be of any interest for someone out there? Do you think i should i publish it on an open source repository ? Or maybe there's already some other software i'm not aware of, that does the same thing? Absolutely a very useful addition to the toolset. Please do release it. thanks for your patience, please excuse my bad english. bye alberto ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
