On Tue, 8 Sep 2003, Taybin Rutkin wrote:
> Here's a ladspa diff with LADSPA_HINT_MOMENTARY and
> LADSPA_HINT_RANDOMISABLE.
>
> Comments please?
What is LADSPA_HINT_RANDOMISABLE actually useful for?
Richard.
Glame 1.0.1 was released moments ago. This release features mp3 and ogg
importing support which was backported from mainline. Also minor bugs were
fixed and LADSPA v1.1 hints are now honoured.
Downloads are from the usual SF.net location
http://prdownloads.sourceforge.net/glame/glame-1.0.1.tar.g
On Wed, 17 Jul 2002, Steve Harris wrote:
> On Wed, Jul 17, 2002 at 06:49:05 +0200, Richard Guenther wrote:
> > Hi Steve!
> >
> > I really like it! Also it opens up a lot of other possibilities in the
> > future like GUI hints, etc.
>
> Yes, it should also pr
hy, but they won't add
> much.
>
> Also in the directory above is a sample plugin description (sample.rdf)
> and a sample defaults file (default-sample.rdf).
>
> Conclusion
>
> Advantages
>
> Its a unified way of describing everything* about plugins, it
on - but the only
kind of short term solution I'd give my personal ok to (not that this
matters).
Btw. Steve - hows RTF (sp?) going?
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
id it then, will say it again:
>
> the proposed mechanism for default values is a kludge.
>
> i'm against it.
Me too. It doesnt provide a real default value and still is so complex
and ugly nobody wants to implement support for this.
Please settle on a preset storage layout/
quick howto on this topic? Preferrably
including some .asoundrc quoting...
Thanks, Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
esets - so we maybe better come up
with a standard on plugin presets. The plugin then could come with a
"standard" preset. The question is wether to separate presets from the
LADSPA API or not.
Oh, I didnt look up the previous discussions about presets.
Richard.
--
Richard Guenther &l
On Sun, May 26, 2002 at 01:52:40PM +0100, Richard W.E. Furse wrote:
> After some more worry about the least untidy way to do defaults, I've come
> up with the following, based on Paul's/Steve's scheme. I'm edging towards
> this as preferable to my previous posting for LADSPA v1.1.
>
> Please let
lso
> be sent to its output ports, causing the data to be audible at the
> same time.
Does this include ports from other clients? I.e. will the engine monitor
an arbitrary port through the driver? That would be useful for debugging.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
; >GLAME we of course use another plugin for this wave generation, but that
> >again is not possible with LADSPA].
>
> Why not?
Because you cannot have source/sink plugins with LADSPA? Only the host
can do those.
Richard.
--
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
t the monitor stuff is doing from the
documentation.
Well - I probably need to allocate a day to hack GLAME to support Jack
before LinuxTag...
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
y [for
GLAME we of course use another plugin for this wave generation, but that
again is not possible with LADSPA].
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Sun, 12 May 2002, Likai Liu wrote:
> Richard Guenther wrote:
>
> >Its certainly possible - but the problem with LADSPA is the host-centric
> >buffer management. Though you could add a callback asking for the output
> >buffer size.
> >
> >Richard.
> >
not impossible) to do correctly.
Its certainly possible - but the problem with LADSPA is the host-centric
buffer management. Though you could add a callback asking for the output
buffer size.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
e dynamically during runtime).
>
> So this is my view on the issue. Let's see what other people think...
Speaking for GLAME the issues are similar - envelopes are handled as
separate stream of data. So this LADSPA extension does not make sense
to me.
Richard.
--
Richard Guenther <
ould cause
> problems.
So why do they have non-static globals anyway? (apart from the ladspa
descriptor function) So fix the plugins, not the hosts...
Richard.
--
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
I'd like to have a 10 minute session for jack-ifying GLAME ;)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
t; - Putting effects on (live) samples (LADSPA)
We can contribute to both of the above.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
Moi!
Glame 0.6.2 is out. This latest version in Glame's current stable branch
includes bug fixes and enhancements in usability. Among the squashed bugs
is a nasty leak in the swapfile that would eat more and more of your
disk space over time. The wave editor now is able to apply a wider
range o
o many to not to care. I think an acceptable policy for LADSPA
plugins would be to have at least code for the weakest available CPU
around (i.e. C code, compiled with -march=i386), additional optimized
code should be used only after run-time detection of the CPU.
Richard.
--
Richard Guenther <[EM
hat a plugin in _no_ case should use
other than plain i386 instructions if no detection is available, and
in the latter case always includes a i386 version for fallback (all
of course assuming x86 CPU type). Otherwise a binary distributed
plugin may cause crashes on low-end machines.
Richard.
on a not-SSE-supporting platform you get SIGILL and
probably a crash of your whole program.
Btw, querying would be not enough, but instead having multiple objects
for each subarchitecture would be necessary - or autodetection of
CPU capability inside the plugin.
Richard.
--
Richard Guenther <
nnot record
more than 2 channels at once (driver plugin problem - we dont have
hardware to test).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
get Glame from the usual download location at
http://prdownloads.sourceforge.net/glame/glame-0.6.1.tar.gz
More information about Glame can be found on
http://glame.sourceforge.net
Have fun, Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
min+(max-min/2) */
>
> Make that "/* set to min+((max-min)/2) */" :-).
Well, even better "/* set to (min+max)/2 */" :-).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
X0x400 /* set to max */
I'd add
#define LADSPA_HINT_DEFAULT 0x40 /* set to LADSPA_PortRangeHint->Default
*/
and add a member to the LADSPA_PortRangeHint structure (at the end, of
course, being available, if the flag is set). Still compatible with
old LADSPA versions.
Richard.
min+(max-min/2) */
>
> Make that "/* set to min+((max-min)/2) */" :-).
Well, even better "/* set to (min+max)/2 */" :-).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
Moi!
There is a new stable series of Glame. Version 0.6.0, released earlier
today, officially marks the end of the 0.5 development cycle. Glame 0.6.0
contains all the features already present in the 0.5.4 snapshot, plus
bugfixes and documentation updates.
Compared to the previous stable releas
d be nice but more than I need. Are there any
> applications out there that will do that?
GLAME will work for this task, too.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
is to do audio editing - but of course with a
well thought filter backend you'd get realtime networks for free, even
if the only thing they were designed for is to be able to visually
construct new effects out of existing ones.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW:
y writing a header _with_ documentation
- then implement
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
dont have recent libaudiofile
(which is 0.2.1 or later) because the internal glame replacement
is broken
- dont start GLAME from within the mozilla install directory, if you
have the flash plugin installed
Have fun, Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW
ets make it consitant with the presets. Taybin?
>
> Looks consistant to me.
Of course you can store presets in the .conf files mentioned in
the LCP metadata thread, too. Just one standard place for
configurable (per plugin) data.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://w
/share/ladspa/pluginname.conf or the like where you can specify
the GUI to use - provide a default.conf for plugins without .conf files
to specify the generic GUI. Also having such a file would allow putting
the property defines there, too (as discussed in the LADSPA extension
thread).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
_not_ care
about GUI design, but can just launch a standard LADSPA-default-gtk-gui
or whatever that handles params via sliders or numerical entries. I dont
think custom GUIs will be popping out en masse, because GUI writing is
somewhat boring :)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Mon, 10 Dec 2001, Steve Harris wrote:
> On Mon, Dec 10, 2001 at 10:09:00 +0100, Richard Guenther wrote:
> >
> > Also what seems to be missing is the API part for querying
> > a host for its plugins and the plugins for its ports.
>
> The idea was that the host wou
the API part for querying
a host for its plugins and the plugins for its ports.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
ocol (http isnt complex) - and using
an existing protocol allows you to use existing clients/servers that
are known to work to debug your implementation (and in case of http
you even get some GUI stuff for free). But well - I dont have time
to implement it, so you're again more fast at coding than w
ith conversion from the char * return type of an
> http_get operation back to the actual port value (when reading a port
> value).
Yep, but I think the advantages outweight the problems.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Fri, 7 Dec 2001, Steve Harris wrote:
> On Fri, Dec 07, 2001 at 03:17:28 +0100, Richard Guenther wrote:
> >
> > Note that we are not speaking of a timing critical part, so always
> > using tcpip will simplify implementation. Also we could make use
> > of existing te
n through
some standard protocol isnt the worst thing I can think of - at least
it'd be cross platform. I dont know java very well, but I can imagine
java having support for the http protocol builtin.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
h in turn can be any browser) either from the LADSPA host
or directly from each plugin.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Fri, 7 Dec 2001, Steve Harris wrote:
> On Fri, Dec 07, 2001 at 10:28:01 +0100, Richard Guenther wrote:
> > > An ontology in other words. Good idea BTW.
> >
> > I even want you to consider a more generic approach for exposing extra
> > information. Add a (
e {
> ... malformed name ...
> }
>
> how does that seem ?
Umm, it will certainly work, though syntactically I'd prefer
an URL style notation [maybe do communication through http
protocol and use a browser for showing the GUI!? I.e. just
have each LADSPA plugin run
s) that,
for the LADSPA plugin running in one thread, in another thread
present a CORBA client (or was it a server?) that accepts parameter/port
changes for the plugin and advertises its possibilities. This CORBA
client/server is obviously part of the LADSPA host, so if anyone wants
to d
On Thu, 6 Dec 2001, Steve Harris wrote:
> On Thu, Dec 06, 2001 at 05:52:47 +0100, Richard Guenther wrote:
> > On Thu, 6 Dec 2001, Paul Davis wrote:
> >
> > > 2 proposals for changes to LADSPA, with the intent of moving LADSPA
> > > v1.0 to LADSPA v2.0.
>
unstructured menus of plugins (GLAME sorts them
into submenus with the first character of the name as submenu name
- ugh!)
For GLAME plugins we have plugin names like effect/echo or
frequency/lowpass.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni
in fact GLAME
does it this way) you need to reference count the actual float array
the pointer points to, so the plugin needs to get() the data and
release() it after working with it, doing this once for each processing
step.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://ww
veform would help, too.
Anything more complex would require too much knowledge of the other
audio type program. You f.i. could link with parts of the glame source
and just call glame_waveedit_gui_new() from your program. But of course
you'd either need to use the glame internal wave representat
d, not by
reading the source).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
by sound
> applications ?
Rather than starting just another project I'd suggest you look at some
of the promising projects and contribute to one of them. You're
probably looking at the concept of EDL, also basic theory of virtual
memory management will help you with the large file issue
This idea is not new - look for example at OpenDX from IBM, which does
caching on nodes in a processing network (but for visualizing scientific
data).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anat
> can someone correct me if i'm wrong about this ability?
You're right wrt GLAME - GLAME does use as much processors as are
currently available (tested on 4-way, dont have a machine with more
processors available here). But it does so by using the operating
systems capability to schedul
cate all resources before fork() (if possible), or
have a resource list in a shm region allocated before fork(). Something
along this should be the simplest (rather than setting up another
comm via sockets or the like).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
doing necessary cleanup. Just like X does
with Xwrapper.
> btw, i have JACK running with maarten's rudimentary FLTK client,
> rythmnlab and the prototypical simple JACK client now. lots of things
> to work on, but its starting to feel very nice.
Nice :)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
ant
> to go th
Well - as shmat does behave the same as mmap (discarding previous
mappings for a fixed address attach), you have to test, if the region is
already occupied (umm, reading and playing with signals - cant think
of another way at the moment). Also segment:offset addressing is not
that di
nt to the same address in different processes.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/
can exchange/cut/insert regions on a copy
on write basis.
I'll try to hack up the region based undo and see, if I encounter
problems.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
he mouse/marker is at"
operation, it should be a matter of minutes to implement this in GLAME,
too (the information is all there).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
API that does this? What are
> the grounds for your fears?
I never looked into JACK, I just know LAAGA and Arts and what Richard
posted about LAMEDA. JACK is the one used within Ardour?
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
o the easy way, drop the need for B, but _dont_ intermix
A with the resulting API (so you can add B later without lots of hassle).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
s by their
first character to not have a menu of plugins that does not fit on
the screen...
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
have a GLAME/GStreamer like API for
the real men that want to do powerful nodes.
See my previous mail - Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
is
already in wide use.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Sun, 5 Aug 2001, Steve Harris wrote:
> On Sun, Aug 05, 2001 at 02:06:18PM +0200, Richard Guenther wrote:
> > On Fri, 3 Aug 2001, Steve Harris wrote:
> >
> > > Hi all,
> > >
> > > I actually want to record some music on my Linux box. I havn't
and it.
I'd like to know whats going wrong - what version are you using? Can
you provide a way to reproduce the bug? Can you provide a backtrace
from within gdb (the best way to do this is to attach to the process
the GNOME crash-dialog is showing)?
Thanx, Richard.
--
Richard Guenther
etting a signal handler that closes audio
> device (if still opened!) is the right way to go. It should be done by the
> default exit routine though so I am not sure if you gain anything.
You're on a UNIX system, so the kernel generally cleans up after you
(i.e. it closes open fds, frees
information.
GLAME handles saving of networks and params via creating scheme code
that is capable of re-creating the saved network. To create a preset
just save an existing filter with the right params under another name.
So a preset is just another filter [you can choose the params yo
aveedit-play (car sel) (+ (car sel) (cdr sel)) #t #f)))
This does check, if we have a selection, if yes, play that and restore
the marker (which is moving during play) after play, if no, just start
playing from the current marker position.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WW
On Fri, 27 Jul 2001, Patrick Shirkey wrote:
> Richard Guenther wrote:
> >
> > Well, people dont stop development on their apps they worked on for
> > one and a half year - this will not happen.
> >
>
> Both you and Paul feel the same way on that topic. I d
Humm, before we started GLAME I had a look at the snd codebase (at that
time the gtk port was not available) and I quickly came to the point
where starting a new project was easier than retrofitting a good backend
into snd - its way too much interwinded GUI/backend stuff.
Richard.
--
Richard G
e we
> are capable of making it so that the gui can be extended in any way.
>
> To put it bluntly. LAD make a mockery of the idea of lazy hackers.
> Everyone is trying to do the same thing over and over and over and.
Well, people dont stop development on their apps they worked on f
ary.
Dynamically linked usually suffices. GLAME 0.4.2 is available as binary
debian package in the unstable distribution, its also included in the
mandrake distribution. I dont know about other distribution, nor if
someone makes GLAME 0.5.2 binary packages available.
Richard.
--
Richard Guenth
reak
> XML-using code. Thats why I prefer to tell people to "get
> libimlib-blah-blah" and "get libxml-foo-foo" than "install GNOME"
> because there's no way to know if they'll end up with the libxml that
> doesn't properly list all child property
n GNOME ...
Err - for which part of GNOME or its dependencies are no binaries
available??? Paul, what are you smoking??? The above is precisely
the problem with adour which certainly doesnt depend on GNOME but
libraries for which no binaries are available...
Richard.
--
Richard Guenther &
e that
> changes quite often is very difficult.
Yes, so you dont develop against a moving target, but against the
stable version (we're not building against gtk2.0 f.i.) - or you at
least dont _depend_ on such libs, but only support them, if available
(like we do with certain alsa versions or liblameenc to mention two).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
libgnome (or gnomesupport, dont know) provides a way to store application
config stuff, also I think the gnome help functionality is hooked there.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
my fade is a linear fade. There needs to be
> representation of commonly expected envelope based amplitude fade, with
> presets for bell, curved and the requisite attack/decay.
>
> Many of your filter gui's are without legend [unit values], and so are
> useless. The worst
ctually at least as important as user interface ones.
Sure.
> But then, I'm still using LaTeX 8-)
Who does not - it is (was) widely spread and so will stay there forever.
Just like the gnome libs - or Qt - or even wxWindows (audacity).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
ime consuming.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
ard-to-compile, seperately distributed
libs. Can you say adour?
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
).
So - contribute to existing projects, rather than creating new ones...
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
t
that is capable of handling large files, unlimited (well, configure that)
undo/redo and has an at least usable user interface. Its functionality
is at least comparable to those of Sweep and gnoise (I dont know
audiacity) and its stable (the wave editing component - at least, we dont
get it crashing
t; ....
>
> Any thoughts? I've written to Werner privately about this idea too.
I like it :)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
On Tue, 26 Jun 2001, Benno Senoner wrote:
> So what's the best IPC method for LAAGA in your opinion ?
> (best tradeoff between speed and flexibility (eg support of poll() ,
> difficulity of graph reordering etc)
Use poll on a pipe or a unix socket.
Richard.
--
Richard Gu
could embed the engine
into the client side library (i.e. a distributed engine with its state
in shared memory).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
but by this syncronization
stream (which in your case happens to be provided by the engine and is
implicit and invisible) - this stream would span the flow-graph. Oh
well...
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
tive.
This is obviously a bug in the quadra app (it has to be considered as
such for my model as else the mixer will stall).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
gt; It is really hard for me to imagine explaining to a non-audio-programmer
> user why the equivalent configuration in LAAGA fails to produce any
> output.
I can see your problem with my approach and I cant offer you a solution
you'd be happy with.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
107a/0107a.htm ...
> for this short reaction. (credit where credit is due + you get a nice
> benchmark extra)
>
>
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
depends on input from audioio:capture:chn2 as
syncronization signal and always produces output (and C3 for the sake
of simple code can now really _depend_ on input from C2 without
problems).
So, if you have a dependency and the graph does not meet it, parts of
the graph may be entirely stalled. Solve this by avoiding dependencies
or by satisfying them.
Richard, who has now mentioned other problems whose solutions Paul will
not like...
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
ss. its an absolutely fundamental object in working with audio, IMHO.
Ok, I then didnt understand what you ment by "bus" - its now clear and
it works similar to the thing I called "crossbar" (but the "crossbar"
does not do mixing, but requires extra mixing nodes - and is type
independend in result)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
h".
The difference (at the receiving point) between my and your model is
sigwait();
process buffer A & B
kill();
v.s.
A = getBuffer(connectionA);
B = getBuffer(connectionB);
process buffer A & B
queueBuffer(portForA, A);
queueBuffer(portForB, B)
able to start processing in the other nodes. So for sync.
> >operation you somehow magically need to detect that delay can produce
> >output without having input first.
>
> once again, this is a free running system. a unit with an output port
> generates output at all times, whether they have connections or
> not.
Sure.
> the delay line produces silence before there is anything
> connected to it. ergo, there is no correct order. if you run the input
So you have implicit (unsynced, for async. operation) zero input all
the time? I dont like this.
> to the delay first, you get one effect. if you run the delay first,
> you get another. all that matters is that you never change the order.
>
> --p
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
'Adder' plugin client but letting the system mix it up!
I dont like having mixing code in the backend - but you can easily
hide the additional mixing node from the user by inserting it implicitly
from the application.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
io of
> fixed length can be injected, but it continues to run before, during
> and after that particular length is done. We don't care about the
> "extension" effect of a delay line, though the application containing
> the delay line probably does. (*)
>
> --p
Ok, we see
You have sync. processing, so the engine has to know if apps "extend"
or "shorten" the audio stream [delay] and it has to explicitly handle
feedback (which you get for free with an async. model) as in:
-->--- mix -->--\>---
/|
\--<--delay---<---volume_adjust--<---/
(which happens to be the layout of our echo2 filter network)
> > If the graph
> >is async. driven - but by audio I/O - async. and sync. operation are
> >the _same_
>
> OK, point taken.
Ah, nice - so we dont argue about sync./async. operation anymore? :)
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
t
knows and handle them, simply ignoring the others. No versioning
problem at all (just the problem of coosing unique identifiers).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
ration inside the app, i.e. use
threads and blocking I/O (probably not a big problem, though).
> - read/write is probably faster (less cycles in kernel). I'm not sure
> however and I doubt the difference is relevant anyway.
signals are faster
Richard.
--
Richard Guenther <[EMAIL
1 - 100 of 109 matches
Mail list logo