Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank yo
On Wed, 2008-01-23 at 13:22 -0500, Darren Landrum wrote:
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it would
On Wed, 2008-01-23 at 13:22 -0500, Darren Landrum wrote:
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it would
Le 23 janv. 08 à 19:22, Darren Landrum a écrit :
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how
> would
> you go about it? It would need to work in real-time, but it wouldn't
>
or write a Csound plugin... just as easy...
- Original Message -
From: "Paul Davis" <[EMAIL PROTECTED]>
To: "Darren Landrum" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, January 23, 2008 6:37 PM
Subject: Re: [LAD] Prototyping algorithms and ideas
> On Wed
Stéphane Letz wrote:
> Le 23 janv. 08 à 19:22, Darren Landrum a écrit :
>
>> Okay, I'll see if I can make up for my awful post from before with a
>> constructive question.
>>
>> If you wanted to quickly prototype an idea for a DSP routine, how
>> would
>> you go about it? It would need to work i
Stéphane Letz wrote:
> Have a look at Faust: http://faust.grame.fr/
Oh, hey! I'd forgotten about Faust. I might have to give that one a go.
Thanks!
And thanks to all the other replies. Csound was already on my short
list, but I'm having troubles getting it working on my AMD64 system for
some r
On 1/23/08, Darren Landrum <[EMAIL PROTECTED]> wrote:
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
>
Am Mittwoch, 23. Januar 2008 schrieb Darren Landrum:
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
> rea
Hernán Ordiales wrote:
> I used to use matlab (or similar/equivalent scripting languages like
> octave or python + scipy + matplotlib +...) but now the CLAM
> framework[1] is my first option. You have the best of both worlds,
> visual prototyping and direct coding (and realtime capable), indeed
> y
Hallo,
Arnold Krille hat gesagt: // Arnold Krille wrote:
> Am Mittwoch, 23. Januar 2008 schrieb Darren Landrum:
> > Okay, I'll see if I can make up for my awful post from before with a
> > constructive question.
> > If you wanted to quickly prototype an idea for a DSP routine, how would
> > you go
Darren Landrum wrote:
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
> really need to be super-efficient for testing ideas.
As long as the DSP doesn't need any tight feedback loops, Pd [1] or some
s
Darren Landrum wrote:
>> [1] http://clam.iua.upf.edu
>
> That one I *didn't* know about. That's almost like Reaktor! I'll
> definitely be giving that one a go. Thanks!
Yes, CLAM is nice. If I'm not mistaken, a new version is around the
corner. And it interfaces to Faust (see my previous reply),
Am Mittwoch, 23. Januar 2008 schrieb Frank Barknecht:
> Arnold Krille hat gesagt: // Arnold Krille wrote:
> > Am Mittwoch, 23. Januar 2008 schrieb Darren Landrum:
> > > Okay, I'll see if I can make up for my awful post from before with a
> > > constructive question.
> > > If you wanted to quickly p
Darren Landrum:
>
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
> really need to be super-efficient
On Thu, 24 Jan 2008, Kjetil S. Matheussen wrote:
>
>
> Darren Landrum:
>>
>> Okay, I'll see if I can make up for my awful post from before with a
>> constructive question.
>>
>> If you wanted to quickly prototype an idea for a DSP routine, how would
>> you go about it? It would need to work
> > If you wanted to quickly prototype an idea for a DSP routine, how would
> > you go about it? It would need to work in real-time, but it wouldn't
> > really need to be super-efficient for testing ideas.
Since everyone else is having a go, I guess this is the thread to
mention Chuck...
http://ch
Hallo,
Albert Graef hat gesagt: // Albert Graef wrote:
> [2] http://faust.grame.fr/
>
> Faust is a purely functional language (signals are streams of samples,
> DSPs are functions operating on those, which can easily combined in
> various ways using Faust's block diagram operators).
Another ver
Stephen Sinclair wrote:
>>> If you wanted to quickly prototype an idea for a DSP routine, how would
>>> you go about it? It would need to work in real-time, but it wouldn't
>>> really need to be super-efficient for testing ideas.
>
> Since everyone else is having a go, I guess this is the thread t
Kjetil S. Matheussen wrote:
> If you _really_ like functional programming and aren't
> afraid to learn a really different syntax, faust might probably
> be a very good alternative. I don't think you'll get the kind of tight
> interactive development environment with it as the other systems
> though
Frank Barknecht wrote:
> Another very new contender is Vessel, a (micro)sound synthesis
> package for Lua:
> http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm
> http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/Wakefield_MSThesis_MAT07_Vessel.pdf
Looks like that thesis was done at CREATE (UCSB). In
Fons Adriaensen:
> I've been searching for real-time audio processing tool that would
> permit rapid prototyping, for at least two years now, and I haven't
> found anything that up to the requirements.
>
That is interesting. Which requirements do you miss
from snd-rt? (I have a list myself, but i
> > Also, nice in the fact that you can do per-sample computations easily,
>
> How ? I seem to have missed something...
Because you can wait in a 1-sample loop?
Yes, it will use your whole CPU for a loop like that, but this thread
is about prototyping. Obviously you'd rewrite in C for a real
app
On Thu, Jan 24, 2008 at 07:44:05AM -0500, Stephen Sinclair wrote:
> > > If you wanted to quickly prototype an idea for a DSP routine, how would
> > > you go about it? It would need to work in real-time, but it wouldn't
> > > really need to be super-efficient for testing ideas.
>
> Since everyone
On Thu, 24 Jan 2008, Albert Graef wrote:
> Kjetil S. Matheussen wrote:
>> If you _really_ like functional programming and aren't
>> afraid to learn a really different syntax, faust might probably
>> be a very good alternative. I don't think you'll get the kind of tight
>> interactive development
Hallo,
Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote:
> The second problem (besides its lack of interactivity) I have about faust
> is that is purely functional. I have programmed lots of code in purely
> functional style, and I like it very much, so thats not the issue. But, I
Frank Barknecht:
> > The second problem (besides its lack of interactivity) I have about faust
> > is that is purely functional. I have programmed lots of code in purely
> > functional style, and I like it very much, so thats not the issue. But, I
> > feel that being forced to work in one paradigm
I came across osw today, I don't know if it fits the bill but I think
it hasn't been mentioned. http://osw.sourceforge.net/
Best Regards
Philipp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mai
Hallo,
Fons Adriaensen hat gesagt: // Fons Adriaensen wrote:
> - a delay line,
> - allowing high-quality fractional-sample delays,
> - at least 12 outputs, for each two controls: delay, gain,
> - smooth 'crossfading' between two control sets, both delay
> and gain, controlled by a GUI or by OS
On Fri, Jan 25, 2008 at 12:57:19PM -0500, Stephen Sinclair wrote:
> > > Also, nice in the fact that you can do per-sample computations easily,
> >
> > How ? I seem to have missed something...
>
> Because you can wait in a 1-sample loop?
>
> Yes, it will use your whole CPU for a loop like that, b
Hallo!
>> - a delay line,
>> - allowing high-quality fractional-sample delays,
>> - at least 12 outputs, for each two controls: delay, gain,
>> - smooth 'crossfading' between two control sets, both delay
>> and gain, controlled by a GUI or by OSC.
>>
>> It should not take more than 20% CPU on
On Tue, 29 Jan 2008, Kjetil S. Matheussen wrote:
> To run it, just paste the text below into the terminal snd-ls
> was started from.
>
Or not. snd-ls hasn't the define-rt-vector-struct macro yet.
To run it, start latest snd and then evaluate (load-from-path
"snd_conffile.scm") and after that th
Fons Adriaensen:
>
> On Fri, Jan 25, 2008 at 12:57:19PM -0500, Stephen Sinclair wrote:
>
Also, nice in the fact that you can do per-sample computations easily,
>>>
>>> How ? I seem to have missed something...
>>
>> Because you can wait in a 1-sample loop?
>>
>> Yes, it will use your whole CPU
Hi Fons,
Here is a quick solution using Faust :
import("filter.lib");
line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
with { g = vslider("gain (dB)", -60, -60, 4, 0.1) : db2linear :
smooth(0.995);
d = nentry("delay (samp)", 0, 0, 1000, 0.1) :
smooth(0.995);
On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote:
> A fully functional jack application can be easily generated using the
> faust2jack command or by pasting the above code in the online faust
> compiler (http://faust.grame.fr). The performances on my Vaio laptop
> (Intel Core 2 CPU T7400
Le 29 janv. 08 à 23:36, Yann Orlarey a écrit :
> Hi Fons,
>
> Here is a quick solution using Faust :
>
> import("filter.lib");
>
> line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
> with { g = vslider("gain (dB)", -60, -60, 4, 0.1) :
> db2linear :
> smooth(0.995);
>
Le 29 janv. 08 à 23:36, Yann Orlarey a écrit :
Hi Fons,
Here is a quick solution using Faust :
import("filter.lib");
line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
with { g = vslider("gain (dB)", -60, -60, 4, 0.1) :
db2linear :
smooth(0.995);
d = nentry(
On Tue, Jan 29, 2008 at 06:25:50PM -0500, Paul Davis wrote:
> On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote:
>
> > A fully functional jack application can be easily generated using the
> > faust2jack command or by pasting the above code in the online faust
> > compiler (http://faust.gra
On Wed, 2008-01-30 at 15:08 +0100, Fons Adriaensen wrote:
> - My usual grunge: unless you want me accidentally
> destroy some very expensive equipment which is not
> even mine, the generated JACK apps
>
> MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
Hear hear. This setting really must
Fons Adriaensen:
>
>> On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote:
>>
>>> A fully functional jack application can be easily generated using the
>>> faust2jack command or by pasting the above code in the online faust
>>> compiler (http://faust.grame.fr). The performances on my Vaio laptop
On Wed, 30 Jan 2008, Kjetil S. Matheussen wrote:
>
>
> The faust program uses 2.1% percent cpu on my xp2800, while
> the snd-rt program now uses 3.8% percent cpu. The reason
Ouch. That was not entirely correct. I forgot to subtract
the cpu usage spent by jacklib in the faust program. I'm
sorry,
Dave Robillard:
>
> On Wed, 2008-01-30 at 15:08 +0100, Fons Adriaensen wrote:
>> - My usual grunge: unless you want me accidentally
>> destroy some very expensive equipment which is not
>> even mine, the generated JACK apps
>>
>> MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
>
> Hear hear.
Le 30 janv. 08 à 15:08, Fons Adriaensen a écrit :
> On Tue, Jan 29, 2008 at 06:25:50PM -0500, Paul Davis wrote:
>
>> On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote:
>>
>>> A fully functional jack application can be easily generated using
>>> the
>>> faust2jack command or by pasting the a
Hi Yann,
> Here is a quick solution using Faust :
>
> ...
> A fully functional jack application can be easily generated using the
> faust2jack command or by pasting the above code in the online faust
> compiler (http://faust.grame.fr). The performances on my Vaio laptop (Intel
> Core 2 CPU T74
On Wed, Jan 30, 2008 at 11:16:24AM -0500, Dave Robillard wrote:
> On Wed, 2008-01-30 at 15:08 +0100, Fons Adriaensen wrote:
> > - My usual grunge: unless you want me accidentally
> > destroy some very expensive equipment which is not
> > even mine, the generated JACK apps
> >
> > MUST NOT
On Wed, Jan 30, 2008 at 11:26:39PM +0100, Kjetil S. Matheussen wrote:
> Yes, exactly. And by default, the auto-connect ports are
> the same as the physical ones. Those with special setups
> are also the ones who must make special configurations.
The ones I complain about are those that don't even
Donnerstag, 31. Januar 2008 Fons Adriaensen:
> One bad example, sadly, is Ardour. Even if I remove
> the auditioner ports and save the session they come
> back and autoconnect to my power amps (*) next time
> the session is loaded.
Seems to be an assumption buglet. Dangerous indeed.
qjackctl's p
Donnerstag, 31. Januar 2008 Arnold Krille:
> How fast is qjackctl? Ii is not an acl in jack directly, it will
> just disconnect the connections as fast as it can after getting to
> know them. But that could be 200 periods after the 5kHz tone
> destroyed Fons' speaker...
Oh, thanks. I wasn't aware
Am Donnerstag, 31. Januar 2008 schrieb Wolfgang Woehl:
> Donnerstag, 31. Januar 2008 Fons Adriaensen:
> > One bad example, sadly, is Ardour. Even if I remove
> > the auditioner ports and save the session they come
> > back and autoconnect to my power amps (*) next time
> > the session is loaded.
>
On Thu, Jan 31, 2008 at 06:39:56PM +0100, Wolfgang Woehl wrote:
> 192 amp lines? What are you up to :)
Making lots of noise :-)
No, seriously, the 176-channel one is a Wave Field Synthesis system.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
Fons Adriaensen wrote:
> 3. All the recursive filters I tested will generate
> denormals if the input is stopped or disconnected.
Yes, same as with most other dsp software. And, as usual, the solution
is to add a little noise in the right places, or cut off a signal which
goes below a certain thr
Kjetil S. Matheussen wrote:
> The second problem (besides its lack of interactivity) I have about faust
> is that is purely functional. I have programmed lots of code in purely
> functional style, and I like it very much, so thats not the issue. But, I
> feel that being forced to work in one par
On Thu, Jan 31, 2008 at 10:06:07AM +0100, Stéphane Letz wrote:
>> - The apps also autosave their state to $HOME/.***rc.
>> Any way to disable this ?
>
> If you want to change that kind behaviour for now,
> ...
One man's 'kind behaviour' is another one's bug.
Just received a mail from on of the
Kjetil S. Matheussen wrote:
> Thanks, that was simple. I'll try figuring out the rest myself.
> But what about resampling? The main main signal usually needs to
> be resampled up 5-10 times to get a decent sound. Can I do that
> with faust? Something like:
>
> process = resample(5,d)
I'm quite cu
On Fri, 1 Feb 2008, Kjetil S. Matheussen wrote:
> fucntions to get a convenient speed boost for dsp processing. A few
> modifications to the faust syntax will be necesarry though to make
> it work in s-expressions, but it shouldn't be so hard.
>
The last sentence was extremely bad formulated. I
On Fri, 1 Feb 2008, Darren Landrum wrote:
> Kjetil S. Matheussen wrote:
> > Thanks, that was simple. I'll try figuring out the rest myself.
> > But what about resampling? The main main signal usually needs to
> > be resampled up 5-10 times to get a decent sound. Can I do that
> > with faust? Somet
On Fri, 1 Feb 2008, Albert Graef wrote:
> Kjetil S. Matheussen wrote:
> > The second problem (besides its lack of interactivity) I have about faust
> > is that is purely functional. I have programmed lots of code in purely
> > functional style, and I like it very much, so thats not the issue. Bu
Kjetil S. Matheussen wrote:
> Thanks, that was simple.
Beware, I haven't tested that code. :)
> But what about resampling? The main main signal usually needs to
> be resampled up 5-10 times to get a decent sound. Can I do that
> with faust? Something like:
>
> process = resample(5,d)
I want tha
On Fri, 1 Feb 2008, Albert Graef wrote:
> Kjetil S. Matheussen wrote:
> > The last sentence was extremely bad formulated. I ment that
> > the syntax for accessing faust needs to be different, because
> > programming in snd is s-expressions based.
>
> So what you need is an unparser for s-expressi
On Fri, Feb 01, 2008 at 07:37:33PM +0100, Albert Graef wrote:
> > But what about resampling? The main main signal usually needs to
> > be resampled up 5-10 times to get a decent sound. Can I do that
> > with faust? Something like:
> >
> > process = resample(5,d)
>
> I want that, too. :) There's
Le 1 févr. 08 à 19:52, Kjetil S. Matheussen a écrit :
> On Fri, 1 Feb 2008, Albert Graef wrote:
>
>> Kjetil S. Matheussen wrote:
>>> The last sentence was extremely bad formulated. I ment that
>>> the syntax for accessing faust needs to be different, because
>>> programming in snd is s-expression
Kjetil S. Matheussen wrote:
> The last sentence was extremely bad formulated. I ment that
> the syntax for accessing faust needs to be different, because
> programming in snd is s-expressions based.
So what you need is an unparser for s-expressions that produces Faust's
infix syntax, this shouldn'
Stéphane Letz wrote:
> The LLVM backend based approach may improve the situation : http://
> www.grame.fr/~letz/faust_llvm.html, the day it will work ((-:
That will enable you to skip the C++ compilation, but Faust still does a
lot of stuff behind the scenes, rewriting expressions to normal form,
Fons Adriaensen wrote:
> Won't be easy I'd think. Both resampling and fractional
> sample delay lead to the same problem with different
> constraints - interpolation.
Sure. But what I meant is that it will then at least be possible to
interface to such algorithms, whereas now there's no way to dea
64 matches
Mail list logo
