2007/3/19, Stefano D'Angelo <[EMAIL PROTECTED]>:
Hi all,
I have a little problem that maybe some of you already faced.
I'm developing a test suite for my library and I wrote some libtool
test modules which I wish to build with automake.
The problem is that using chec
Hi all,
I have a little problem that maybe some of you already faced.
I'm developing a test suite for my library and I wrote some libtool
test modules which I wish to build with automake.
The problem is that using check_LTLIBRARIES or noinst_LTLIBRARIES
dynamic modules are not built, but only stat
2007/2/26, Fons Adriaensen <[EMAIL PROTECTED]>:
Hi Stefano,
> >> I still don't know if I can get there...
> >> I got really disappointed to see that there's no easy way to get to
> >> Berlin via train from Turin, I'm considering bus, and I need someone
> >> else to come with me too... :-(
You c
2007/2/26, nescivi <[EMAIL PROTECTED]>:
On Thursday 22 February 2007 18:51, Stefano D'Angelo wrote:
> I still don't know if I can get there...
> I got really disappointed to see that there's no easy way to get to
> Berlin via train from Turin, I'm considerin
el mailing list
(http://lists.sourceforge.net/mailman/listinfo/naspro-devel).
I've also set up a SVN repository with some code I wrote for it
(http://sourceforge.net/svn/?group_id=190105).
Any feedback is appreciated.
Enjoy,
Stefano D'Angelo
[EMAIL PROTECTED]
2007/2/22, Carlo Trimarchi <[EMAIL PROTECTED]>:
> Well, what exactly do you want to build: an end-user application or a
> performance environment, installation ?
My intention was to build an end-user application.
One plays notes on the keyboard and it memorizes and shows them on a
staff. There y
2007/2/22, Carlo Trimarchi <[EMAIL PROTECTED]>:
Hi, I need to build an application that can process sound from an
external instrument (a midi keyboard, for example). I also need to
create a graphic interface and I'd like to know which language maybe
best to do this.
Any suggestion?
Thanks, bye.
2007/2/22, Frank Barknecht <[EMAIL PROTECTED]>:
Hallo,
Stefano D'Angelo hat gesagt: // Stefano D'Angelo wrote:
> I still don't know if I can get there...
> I got really disappointed to see that there's no easy way to get to
> Berlin via train from Turin, I&#x
2007/2/22, Albert Graef <[EMAIL PROTECTED]>:
Stefano D'Angelo wrote:
> I still don't know if I can get there...
A cheap flight maybe?
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
WWW:http:/
I still don't know if I can get there...
I got really disappointed to see that there's no easy way to get to
Berlin via train from Turin, I'm considering bus, and I need someone
else to come with me too... :-(
What about Italy for next year? :-P
2007/2/22, Frank Barknecht <[EMAIL PROTECTED]>:
Ha
> > > you can think all you want. unless there a plugin->host callback that
> > > allows the plugin to determine its operating environment in huge detail,
> > > this kind of idea is pretty impossible to make use of.
> >
> > What?
> > Once again: misunderstood! These optimizations involve that the
2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
Stefano D'Angelo wrote:
> 2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
>> Stefano D'Angelo wrote:
>> > 2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
>> >> Jeff McClintock wrote:
>
2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
Stefano D'Angelo wrote:
> 2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
>> Jeff McClintock wrote:
>> > >>>I actually don't know how many plugins are LTI, but, for example, a
>> > >
2007/2/19, Paul Davis <[EMAIL PROTECTED]>:
On Mon, 2007-02-19 at 14:18 +0100, Stefano D'Angelo wrote:
> > How often are more than one plugin with the same control inputs used in
> > paralel? I was rather thinking of colapsing (or swapping) plugins in
> > series.
2007/2/19, Camilo Polyméris <[EMAIL PROTECTED]>:
Jeff McClintock wrote:
> >>>I actually don't know how many plugins are LTI, but, for example, a
> >>>lot of delays, reverbs, choruses, eq. filters, compressors, modulators
> >>>and "sound mixers" should be, and that's quite enough after all.
>
> Ye
2007/2/18, Jeff McClintock <[EMAIL PROTECTED]>:
>>>I actually don't know how many plugins are LTI, but, for example, a
>>>lot of delays, reverbs, choruses, eq. filters, compressors, modulators
>>>and "sound mixers" should be, and that's quite enough after all.
Yeah, It's a good optimization.
2007/2/17, Stefano D'Angelo <[EMAIL PROTECTED]>:
2007/2/17, Camilo Polyméris <[EMAIL PROTECTED]>:
>
> >>> Ok, i get the context now. As you say, I'am both teacher and researcher,
> >>> but my field is Software Engineering and my knowledge on t
2007/2/17, Camilo Polyméris <[EMAIL PROTECTED]>:
>>> Ok, i get the context now. As you say, I'am both teacher and researcher,
>>> but my field is Software Engineering and my knowledge on theoretical DSP
>>> is not that mature, so don't take my DSP related statements so serious.
>>> To my level o
2007/2/16, Loki Davison <[EMAIL PROTECTED]>:
On 2/15/07, Stefano D'Angelo <[EMAIL PROTECTED]> wrote:
> 2007/2/14, Xavier Amatriain <[EMAIL PROTECTED]>:
> > Hard to jump in the thread at this point, but let me try...
> >
> > I agree that the plugi
2007/2/14, Xavier Amatriain <[EMAIL PROTECTED]>:
Hard to jump in the thread at this point, but let me try...
I agree that the plugin approach is severely flawed in many senses
(including the false sense of "freedom" that gives to developers that
are then caught in proprietary specifications). Ha
2007/2/14, Stephen Sinclair <[EMAIL PROTECTED]>:
> What about a text file with a math formula within it to be used as a
> "processing object"?
> Ok, it's not a piece of code, but...
sounds a bit like FAUST.
http://faust.grame.fr/
Well, FAUST developers could take advantage of such wrapper too
2007/2/14, Paul Coccoli <[EMAIL PROTECTED]>:
On 2/14/07, Stefano D'Angelo <[EMAIL PROTECTED]> wrote:
> I understand that most of you don't feel the need to have such thing,
> because LADSPA support is everywhere and lots of LADSPA plugins are
> good, but from my po
2007/2/14, Leonard Ritter <[EMAIL PROTECTED]>:
On Wed, 2007-02-14 at 10:21 +0100, Stefano D'Angelo wrote:
> I understand that most of you don't feel the need to have such thing,
> because LADSPA support is everywhere and lots of LADSPA plugins are
> good, but from m
2007/2/14, David García Garzón <[EMAIL PROTECTED]>:
On Tuesday 13 February 2007 15:06:27 Stefano D'Angelo wrote:
> > Yes, it's very interesting and it is a path we want to walk. Currently,
> > apart of building Ladspa plugins, CLAM also can be a Ladspa host and we
>
Hi,
Leonard, I know what you mean, for me it would be easier too to just
learn one, pick it up, let go the others and not creating much more
confusion with a wrapper.
I perfectly understand also that wrappers usually add unneeded
complexity, which is obviously the worst thing to do, especially wit
l H(f)s
following a certain path and use this result as the H(f) of the whole
network. This would allow network-based optimization (but obviously
the wrapper would have to know how the net is made).
Well, it seems like you're a teacher or a researcher, so you probably
know more than me about these stuff.
This, however, is just a thought.
In case I wasn't clear enough, just tell me.
Regards,
Stefano D'Angelo
2007/2/13, David García Garzón <[EMAIL PROTECTED]>:
On Monday 12 February 2007 21:34:08 Stefano D'Angelo wrote:
> > Well, that's our intent in CLAM[1]. The goal is that CLAM should be able
> > to run a given processing algorithm transparently under several backends.
If you meant a wrapper to handle the plugin formats on Linux in general
and transparent way, its a tough goal too. One tricky part is different
UI handling. I remember being annoyed by Apple and their constant change
of the UI handling of their AudioUnits so I gave up on the end. I expect
they cha
Hi all,
who would be interested in writing a processing plugin standard
wrapper (LADSPA, DSSI, LV2, VST, etc.)?
2007/2/12, Malte Steiner <[EMAIL PROTECTED]>:
Stefano D'Angelo wrote:
> Hi all,
> who would be interested in writing a processing plugin standard
> wrapper (LADSPA, DSSI, LV2, VST, etc.)?
>
>
As far as I know, DSSI accepts OSC for controling so you could use the
OSC
Hi,
maybe it's just another of my dumb questions, however I would like to
know whether it is happened to you that a sound processing plugin
(LADSPA, LV2, VST, etc.) crashed (segm. faults, etc.).
In such case, can you estimate how often does it happen that such
plugins are misprogrammed?
Thanks in
Thanks a lot to everyone :-)
Stefano
It's all somewhat a matter of taste though.
I do agree :-)
2007/1/24, Steve Harris <[EMAIL PROTECTED]>:
The way to help, IMHO, would be to make the existing systems
compatible, using bridges/reflectors/wrappers, rather than creating
more specs.
- Steve
Honestly I don't know about PluginCore, however that's not necessairly true.
Although it is a comple
ugins). Is that "naturally" possible, is it an hack or is
it impossible at all?
And another thing (I'm too lazy to check it out myself :-P): does jack
transfers data by copying or uses something like shared memory or
whatever?
Thanks is advance.
Stefano D'Angelo
2007/1/24, Jay Vaughan <[EMAIL PROTECTED]>:
At 20:08 +0100 22/1/07, Stefano D'Angelo wrote:
>What I'd like to work on is a sound processing architecture (LADSPA,
>VST, DSSI, etc.) wrapper, which hides the details of a particular
>implementation to audio program develop
2007/1/23, Steve Harris <[EMAIL PROTECTED]>:
On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote:
>
> Just some last questions and I'll stop shouting and fooling around :-)
>
> This issue should also have been faced with vstserver, fst and so, but
> I never used them
2007/1/23, Steve Harris <[EMAIL PROTECTED]>:
On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote:
> 2007/1/23, Steve Harris <[EMAIL PROTECTED]>:
>>
>> On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
>> >>
>> >> You need to read the s
2007/1/23, Steve Harris <[EMAIL PROTECTED]>:
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
>>
>> You need to read the spec again.
>>
>> The terminology is confused, not least in the spec documents, but a
>> single .lv2 "plugin" can host
2007/1/23, Steve Harris <[EMAIL PROTECTED]>:
On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote:
> 2007/1/22, Dmitry Baikov <[EMAIL PROTECTED]>:
>> On 1/23/07, Stefano D'Angelo <[EMAIL PROTECTED]> wrote:
>> > Good point! This is true, but there are lo
Anyway, I gave a fast look at the include/zzub/plugin.h file and it
seems me like it's a valid example of a plugin system which could be
implemented on the top of an architecture such as the one I'm
describing right here. (You were meaning this, right?)
Regards,
Stefano
2007/1/22, Dmitry Baikov <[EMAIL PROTECTED]>:
On 1/23/07, Stefano D'Angelo <[EMAIL PROTECTED]> wrote:
> Good point! This is true, but there are lots of sound processing
> plugins around, so maybe instead of creating a new API and then apply
> some "compatibility
2007/1/22, Leonard Ritter <[EMAIL PROTECTED]>:
might libzzub be part of what you are searching for?
http://trac.zeitherrschaft.org/zzub
Well, what do you mean for "extensible DSP plugin system"?
Let me know,
Stefano
2007/1/22, Dmitry Baikov <[EMAIL PROTECTED]>:
On 1/22/07, Stefano D'Angelo <[EMAIL PROTECTED]> wrote:
> What I'd like to work on is a sound processing architecture (LADSPA,
> VST, DSSI, etc.) wrapper, which hides the details of a particular
> implementation to aud
xisting ones.
What do you think about it?
Sincerely,
Stefano D'Angelo
Well, this topic truly interests me. I am the main developer of FreeADSP, my
name's Stefano, and this is the first time I write in here.
You know, in my application I'll try to make different kind of audio
processing plugins work together using a compatibility layer (plugin loader
plugins).
I re
46 matches
Mail list logo
