[Jens M Andreasen]
>Tim Goetze offered to me (in a background discussion, sorry Tim) to
>write a wellcommented boilerplate jack.c
no problem. i'm happy to extend the offer should anyone need more than
the sample code the jack distribution and clients provide.
sorry i didn't get back to you, Jens.
On lör, 2004-03-06 at 21:01, Arnold Krille wrote:
> On Saturday 06 March 2004 19:59, Steve Harris wrote:
Hi Krille!
>
You are not the only one skipping ahead to get the big picture :)
> > Yes, but the difference to new developers is huge, they must understand
> > everything in the .h file befo
On Sat, Mar 06, 2004 at 09:01:59PM +0100, Arnold Krille wrote:
> On Saturday 06 March 2004 19:59, Steve Harris wrote:
>
> > Yes, but the difference to new developers is huge, they must understand
> > everything in the .h file before thay can write a plugin or host.
>
> I disagree, new developers
On Saturday 06 March 2004 19:59, Steve Harris wrote:
> Yes, but the difference to new developers is huge, they must understand
> everything in the .h file before thay can write a plugin or host.
I disagree, new developers need easy howto's, good docs and examples to write
new stuff. I for exampl
On Sat, Mar 06, 2004 at 05:45:03 +0100, Tim Goetze wrote:
> [Steve Harris]
> >If you look back through the archives you'l see that my attitude changed
> >form "yay, more features, cram them in" (luckily rained in by Paul and
> >Richard) to a more considered attitude.
>
> and now we all have a soli
my apologies to everyone involved in bad cross-posting practices on my
part, particularly Fons. i promise i'll try not to let it become a
habit in the future.
[Steve Harris]
>If you look back through the archives you'l see that my attitude changed
>form "yay, more features, cram them in" (luckily
prologue: this mail is not intended to be a smooth read. if you have
any kids around, tell them to play somewhere else please. i am an
impatient, flawed kind of character quick to give in to a sudden
temper.
[Steve Harris]
>> i'm not sure a studio professional will agree with your estimation of
>>
On Sat, Mar 06, 2004 at 03:26:04 +0100, Tim Goetze wrote:
> [Fons Adriaensen]
> >On Fri, Mar 05, 2004 at 09:56:01PM +0100, Tom Szilagyi wrote:
> >
> >> I think the "dead end" has just been reached...
> >
> >Yes. Steve has made his position very clear: he opposes any change
> >to ladspa.h. Much as I
[Fons Adriaensen]
>On Fri, Mar 05, 2004 at 09:56:01PM +0100, Tom Szilagyi wrote:
>
>> I think the "dead end" has just been reached...
>
>Yes. Steve has made his position very clear: he opposes any change
>to ladspa.h. Much as I respect Steve for all his contributions to
>Linux Audio, I think this i
On Sat, Mar 06, 2004 at 02:28:20 +0100, Tim Goetze wrote:
> >> * everything labeled 'meta' in the above thought experiment becomes
> >> 'not meta', except for the presets.
> >> * knowing that 0.5 = half a second is 'not meta'.
> >> * knowing that 0 = sin, 1 = tri, 2 = saw is vital, thus 'not meta
[Steve Harris]
>On Fri, Mar 05, 2004 at 11:21:32 +0100, Tim Goetze wrote:
>> what do we have in ladspa that is *not* 'meta'?
>>
>> * we have a plugin.
>> * the plugin has n ports.
>> * it also offers certain methods to carry out operations for us.
>
>Thats not feindish, or unfair, its almost correc
On Fri, Mar 05, 2004 at 11:21:32 +0100, Tim Goetze wrote:
> like others, i'm not quite sure discussing this any further is going
> to be particularly fruitful, but here goes anyway.
Agreed. I think we should all sleep on it for a few days at least.
> i would like to carry your definition to the
[Steve Harris]
> We've got on without them for 4 years (bar TAP reverb preset
> selection, but that is a mis-implementation IMHO).
>
> I can't think of any hosts that need enumerations but not RDF for
> other things (accurate defaults, presets, categorisation).
>
> En
On Fri, Mar 05, 2004 at 08:15:24 +0100, Dr. Matthias Nagorni wrote:
> We do not lose anything if we accept either the proposal by Tim or Fons or
> something in between. Both proposals are binary compatible with the
> current standard. Plugin-writers and host-developers would still have the
> cho
On Fri, 5 Mar 2004, Steve Harris wrote:
> > there is one: it seems consensus that making RDF mandatory for
> > hosts should be avoided.
>
> Absolutly. I think scales and enumerations are not mandatory (Matthias
> disagrees, but I dont see any evidence ot the contrary).
Just as my personal conclu
On Fri, Mar 05, 2004 at 05:57:28PM +0100, Tim Goetze wrote:
> [Richard Spindler]
>
> >Is it possible to use this Rdf-Stuff to add all the Features ladspa
> >seems to be missing?
> >
> >And If so, you'll all hopefully agree, that this implementation _works_.
> >
> >And if it works, I do not see any
On Fri, Mar 05, 2004 at 04:48:35PM +0100, Alfons Adriaensen wrote:
> On Fri, Mar 05, 2004 at 03:30:46PM +, Steve Harris wrote:
>
>
> > I still dont think that listing
> > some hardcoded presets in an integer control port is a good way to have
> > presets. It screws up automation for one thing
On Fri, 5 Mar 2004, Tom Szilagyi wrote:
> (Oh, and i didn't mention AMS -- Matthias Nagorni wrote a hack (thanks!)
> that makes the reverb look nicer, not that fixes its breakage.)
Tom, it looks quite broken in AMS without the hack. But let's look forward:
> Anyway, the progress towards a new so
[Alfons Adriaensen]
>On Fri, Mar 05, 2004 at 05:19:58PM +0100, Tim Goetze wrote:
>> [Alfons Adriaensen]
>> >Provided the scale points for a continuous control correspond to the integer
>> >values, then we could use HINT_ENUMERATED without HINT_INTEGER. There would
>> >be a string for each integer
[Richard Spindler]
>Is it possible to use this Rdf-Stuff to add all the Features ladspa
>seems to be missing?
>
>And If so, you'll all hopefully agree, that this implementation _works_.
>
>And if it works, I do not see any reason to change this stuff...
there is one: it seems consensus that makin
This Diskussion is getting rather complicated, but I'm trying hard to
follow :)
Steve Harris schrieb:
Its not that LADSPA is missing combo slections, its just that thier not
labelled - users have to look in the docs. Momentary switches are just not
there at all.
Is it possible to use this Rdf-Stu
[[me]]
> > Yes, particular plugins like my reverb or other fairly complex ones
> > could use some extra possibilities, but that can be satisfied by an
> > external and *optional* set of metadata, and i don't see why RDF won't
> > be good for this purpose. The metadata should be (and currently, it
>
On Fri, Mar 05, 2004 at 05:19:58PM +0100, Tim Goetze wrote:
> [Alfons Adriaensen]
> >Provided the scale points for a continuous control correspond to the integer
> >values, then we could use HINT_ENUMERATED without HINT_INTEGER. There would
> >be a string for each integer value in the port range. S
[Alfons Adriaensen]
>Provided the scale points for a continuous control correspond to the integer
>values, then we could use HINT_ENUMERATED without HINT_INTEGER. There would
>be a string for each integer value in the port range. Some could be NULL
>if required.
i think steve's objection that we a
On Fri, Mar 05, 2004 at 04:11:35PM +0100, Matthias Nagorni wrote:
> On Fri, 5 Mar 2004, Steve Harris wrote:
>
> > OK, thats a reasonable definition for enumerations, but its missing the
> > non-ionteger eqivalent, "scale points" or whatever you want to callthem,
> > eg in ringmod_2i1o(1188) "Modul
On Fri, Mar 05, 2004 at 03:30:46PM +, Steve Harris wrote:
> I still dont think that listing
> some hardcoded presets in an integer control port is a good way to have
> presets. It screws up automation for one thing.
Could you explain that ?
> All of the features missing from LADSPA seem n
On Fri, Mar 05, 2004 at 04:11:35PM +0100, Matthias Nagorni wrote:
> On Fri, 5 Mar 2004, Steve Harris wrote:
> > OK, thats a reasonable definition for enumerations, but its missing the
> > non-ionteger eqivalent, "scale points" or whatever you want to callthem,
> > eg in ringmod_2i1o(1188) "Modula
On Fri, Mar 05, 2004 at 04:11:35 +0100, Dr. Matthias Nagorni wrote:
> On Fri, 5 Mar 2004, Steve Harris wrote:
>
> > OK, thats a reasonable definition for enumerations, but its missing the
> > non-ionteger eqivalent, "scale points" or whatever you want to callthem,
> > eg in ringmod_2i1o(1188) "Mod
On Fri, Mar 05, 2004 at 03:57:39 +0100, Dr. Matthias Nagorni wrote:
> > That is not complete, you also need strings, push-to-make (momentary)
>
> Yes, triggers would be helpful as well. But somehow they can be
> "approximated" by toggles, although it's not ideal. So why not also add
> a HINT_TRIG
On Fri, 5 Mar 2004, Steve Harris wrote:
> OK, thats a reasonable definition for enumerations, but its missing the
> non-ionteger eqivalent, "scale points" or whatever you want to callthem,
> eg in ringmod_2i1o(1188) "Modulation depth (0=none, 1=AM, 2=RM)" input,
> control, 0 to 2, default 0. its
On Fri, 5 Mar 2004, Steve Harris wrote:
> That is not complete, you also need strings, push-to-make (momentary)
Yes, triggers would be helpful as well. But somehow they can be
"approximated" by toggles, although it's not ideal. So why not also add
a HINT_TRIGGER ?
> I agree that combo boxes ar
On Fri, Mar 05, 2004 at 02:40:08 +0100, Alfons Adriaensen wrote:
> > eg. gate(1410) has -1.0 -> "key listen", 0.0 -> "gate", 1.0 -> "bypass"
> > and you might reasonably want non integer values for enumerations.
> >
> > - Steve
>
> HINT_ENUMERATED must always be used together with HINT_INTEGER.
>
On Fri, Mar 05, 2004 at 12:39:56PM +, Steve Harris wrote:
> On Fri, Mar 05, 2004 at 01:11:29PM +0100, Alfons Adriaensen wrote:
> > And all it takes is just one hint bit saying that the port is enumerated.
> > The strings themselves are placed in the portnames array, after all the
> > portnames,
On Fri, Mar 05, 2004 at 01:11:29PM +0100, Alfons Adriaensen wrote:
> And all it takes is just one hint bit saying that the port is enumerated.
> The strings themselves are placed in the portnames array, after all the
> portnames, so no new fields are required. The existing range hints will
> tell t
On Fri, Mar 05, 2004 at 12:21:42PM +0100, Matthias Nagorni wrote:
> Steve, I can not agree with any of these three sentences. My experience with
> ams and real analogue synths show that _any_ synth needs named switches.
> Already the first Moog modules had them. And all of my analogue synths
> h
On Fri, Mar 05, 2004 at 12:21:42 +0100, Dr. Matthias Nagorni wrote:
> > Because they weren't thought of at design time. There is allready
> > enumerated value support in RDF. Very simple hosts do not need it.
>
> Steve, I can not agree with any of these three sentences. My experience with
> ams a
On Thu, 4 Mar 2004, Dave Robillard wrote:
> The categorisation is well worth it though (and would be a really nice
> thing to have in AMS actually)
I agree. And this feature is something I could agree to use RDF for.
It's nice but optional. OTOH an enumeration HINT to build combobox
selectors i
On Fri, 5 Mar 2004, Steve Harris wrote:
> On Fri, Mar 05, 2004 at 02:02:10 +0100, Fons Adriaensen wrote:
> > The other thing that's missing is support for enumerated values such
> > as your presets, or for a simple n-position switch. If all the rest
> > (continuous and integer values, limits, de
On Fri, Mar 05, 2004 at 02:02:10 +0100, Fons Adriaensen wrote:
> > Agreed. I basically believe that the ladSpa spec. is almost completely
> > OK. However, one thing i would change is that i can't specify an
> > arbitrary default for a control but only fixed ones eg. 0, 1, 100, 440.
> > It would be
On Fri, Mar 05, 2004 at 03:15:14 +0100, Fons Adriaensen wrote:
> The functionality provided by the port descriptors is basically OK, what
> *is* missing are the enumerated values - you need these to have sensible
> labels on an n-way switch for example. And that's a very common thing on
> a synth m
On Fri, Mar 05, 2004 at 02:10:30 +0100, Tim Goetze wrote:
> >Hosts that just want to render the units after slider can just ask "whats
> >the label for port 3's units", whereas hosts that want to do tempo -> time
> >mapping for eg. can ask what they are and what thier relation to seconds
> >is.
>
On Thu, Mar 04, 2004 at 07:34:48 +0100, Fons Adriaensen wrote:
> On Thu, Mar 04, 2004 at 04:48:09PM +, Steve Harris wrote:
> > On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons Adriaensen wrote:
> > > I had a look at the TAP RDF file, and compared the useful contents to the
> > > file lenght. The
On Thu, Mar 04, 2004 at 11:57:07PM +, Steve Harris wrote:
> On Thu, Mar 04, 2004 at 01:38:32 -0500, Dave Robillard wrote:
> > On the other hand, the list organized by library is a handy feature too
> > (that lrdf-using hosts I've seen seem to lack), especially when you get
> > a new plugin set
On Fri, Mar 05, 2004 at 02:10:30AM +0100, Tim Goetze wrote:
> dancing forever around the S in ladspa, yelling 'heretic' at any
> extension proposal, is only going to make us the fools of the
> universe. we only have this standard and things are evolving, and so
> it also must.
I couldn't agree m
[Steve Harris]
>> yes, may it :) and agreed again. concerning presets, help text, value
>> scales, value range coloring etc etc, i'm all for storage external to
>> the plugin. in contrast, information of immediate importance: latency,
>> refined defaults and unit identifiers ("dB", "ms", ...) shoul
On Thu, Mar 04, 2004 at 10:02:58PM +0100, Tom Szilagyi wrote:
> As an engineer a chill comes over my back if i think about the
> possibility of breaking something that works now.
As a system engineer a chill comes over my back if I think about the
necessity of having to take into account a mix of
On Thu, Mar 04, 2004 at 01:38:32 -0500, Dave Robillard wrote:
> On the other hand, the list organized by library is a handy feature too
> (that lrdf-using hosts I've seen seem to lack), especially when you get
> a new plugin set and want to try things out.
Its not obvious, but plugin libraries can
On Fri, Mar 05, 2004 at 12:12:23 +0100, Tim Goetze wrote:
> i agree to your reasoning and your concerns seem valid to me. yet i do
> not think this is as much of an issue as it may seem now: the core
> functionality is in ladspa 1.1, and it is proven usable.
Absolutly - that doesnt mean it cant be
> [Matthias Nagorni]
> > The combination of the very simple LADSPA api with something as
> > complicated as RDF seems a bit odd to me. I would wish if there was a
> > simpler solution.
>
> We agree it's not a simple solution. But it's a solution anyway :)
> To me, the idea of a solid, stable co
On Thu, Mar 04, 2004 at 10:02:58 +0100, Tom Szilagyi wrote:
> [Steve Harris]
> >I'm begining to think that it should have been a fixed value (in RDF of
> >course ;) and plugins with varying latnecy shouldn't be corrected for).
>
> Shouldn't be functionality have a priority over simplicity or ease
[Tom Szilagyi]
>[Tim Goetze]
>> so at the end of the version 1 descriptor struct we can add fields
>> galore, starting, obviously, with a version field. of course plugins
>> must not rely on version 2 features if they are intended to work with
>> pre-version 2 hosts.
>
>This last sentence is partic
On Thu, Mar 04, 2004 at 01:42:06 -0500, Dave Robillard wrote:
> > so at the end of the version 1 descriptor struct we can add fields
> > galore, starting, obviously, with a version field. of course plugins
> > must not rely on version 2 features if they are intended to work with
> > pre-version 2 h
Hi all,
It was very interesting to read all your opinions.
Here are mine. :)
[Steve Harris]
I'm begining to think that it should have been a fixed value (in RDF of
course ;) and plugins with varying latnecy shouldn't be corrected for).
Shouldn't be functionality have a priority over simplicity or
[Dave Robillard]
>On Thu, 2004-03-04 at 12:28, Tim Goetze wrote:
>> [Steve Harris]
>>
>> >Mostly default values. RDF defaults for LADSPA predate ladspa.h default
>> >hints, which are a hack.
>> >
>> >> To me this is a mess. It should be perfectly possible to extend the port
>> >> descriptors in su
On Thu, Mar 04, 2004 at 04:48:09PM +, Steve Harris wrote:
> On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons Adriaensen wrote:
> > I had a look at the TAP RDF file, and compared the useful contents to the
> > file lenght. The ratio of these two puts RDF in the 'bloated' category.
> > And it's no
On Thu, 2004-03-04 at 12:28, Tim Goetze wrote:
> [Steve Harris]
>
> >Mostly default values. RDF defaults for LADSPA predate ladspa.h default
> >hints, which are a hack.
> >
> >> To me this is a mess. It should be perfectly possible to extend the port
> >> descriptors in such a way that things like
On Thu, 2004-03-04 at 09:57, Matthias Nagorni wrote:
> On Thu, 4 Mar 2004, Uwe Koloska wrote:
>
> > isn't the right thing to do to use the RDF metatadata?
>
> The combination of the very simple LADSPA api with something as
> complicated as RDF seems a bit odd to me. I would wish if there was a
[Steve Harris]
>Mostly default values. RDF defaults for LADSPA predate ladspa.h default
>hints, which are a hack.
>
>> To me this is a mess. It should be perfectly possible to extend the port
>> descriptors in such a way that things like preset names, scale ticks,
>> units etc. are available from
On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons Adriaensen wrote:
> I had a look at the TAP RDF file, and compared the useful contents to the
> file lenght. The ratio of these two puts RDF in the 'bloated' category.
> And it's not easy to read or write at all.
It is not a problem if you use a libr
On Thu, Mar 04, 2004 at 03:27:32PM +, Steve Harris wrote:
> On Thu, Mar 04, 2004 at 03:57:32 +0100, Dr. Matthias Nagorni wrote:
> > On Thu, 4 Mar 2004, Uwe Koloska wrote:
> >
> > > isn't the right thing to do to use the RDF metatadata?
> >
> > The combination of the very simple LADSPA api wit
On Thu, Mar 04, 2004 at 03:57:32 +0100, Dr. Matthias Nagorni wrote:
> On Thu, 4 Mar 2004, Uwe Koloska wrote:
>
> > isn't the right thing to do to use the RDF metatadata?
>
> The combination of the very simple LADSPA api with something as
> complicated as RDF seems a bit odd to me. I would wish i
On Thu, 4 Mar 2004, Uwe Koloska wrote:
> isn't the right thing to do to use the RDF metatadata?
The combination of the very simple LADSPA api with something as
complicated as RDF seems a bit odd to me. I would wish if there was a
simpler solution.
Anyway, I have hacked it into ams: There is a
Hello,
Matthias Nagorni wrote:
This plugin looks very interesting. I am considering to
modify the LADSPA host module of AlsaModularSynth so that the
presets would appear in a combobox selector. However it's
even more complicated than I thougt: If I print out the
parameter name, I get:
> Presets .
On Thu, Mar 04, 2004 at 12:27:42 +0100, Dr. Matthias Nagorni wrote:
> On Wed, 3 Mar 2004, Tom Szilagyi wrote:
>
> > > * Fixed yet another crashing bug in TAP Reverberator (which appears
> > > to be introduced upon fixing the previous crashing bug).
> > > Hopefully no more crashing in my favori
On Wed, 3 Mar 2004, Tom Szilagyi wrote:
> > * Fixed yet another crashing bug in TAP Reverberator (which appears
> > to be introduced upon fixing the previous crashing bug).
> > Hopefully no more crashing in my favorite plugin :)
This plugin looks very interesting. I am considering to modify t
65 matches
Mail list logo
