Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA v1.1 Alternative Proposal
From: Stefan Kost (kost_AT_imn.htwk-leipzig.de)
Date: Fri May 31 2002 - 10:16:16 EEST


I am +1 for RDF (as XML-files).
I would say, we just need a naming convention for the default-preset (e.g. mysynth/.default.prs).
This would have the advantage, that the user could e.g. say use current-settings
as default and they get written to this file.
Useing such an approach mean no change to the plugins at all.
What we probably need is a library to handle presets for ladspa hosts (in the same way we need a library which does the GUI).
This lib could deliver a simple API to hide the naming stuff as well as the fact that there is RDF and XML under the hood.

Stefan

>>do you agree that defaults are really a preset?
>
>
> Only if there are more than one. A system that includes only one
> predefined set of parameter values, sets the parameters to these values
> during initialization, and always performs an initialization on startup,
> is a system that uses defaults that are not presets. Such a system is
> too primitive to be fun. A default is a preset when the system includes
> multiple predefined sets of parameter values, and the system has some
> rules for choosing which set is used at startup.
>
>
>>since you've already agreed that we need defaults, and since i find it
>>hard to argue with the idea that defaults are presets, i personally
>>find the conclusion that we actually need an API for presets fairly
>>compelling.
>
>
> Presets are great. From a user perspective, presets mean three things:
>
> 1) What parameter values are loaded at startup.
> 2) Access to a list of predefined sets of parameter values, the presets,
> and the ability to apply any one preset at will.
> 3) Ability to add the current configuration to the list of presets.
>
> 2 and 3 are straightforward, but 1 is not. I have used lots of hardware
> synths and fx boxes, and there is quite a difference in the way these
> things power up. These differences are meaningful in the area of user
> friendliness. Here is the basic evolution.
>
> Method 1) The system contains a numbered list of presets and always
> installs preset 00 on startup.
>
> Method 2) The system adds the ability to remember the number of the last
> preset used before shut down, and installs this preset on startup.
>
> Method 3) The system adds the ability to remember the actual parameter
> values in current use without requiring the user to formally save these
> values as a preset. On startup this system restores all parameter
> values to their last known state.
>
> While I'm not completely familiar with the term, I guess that method 3
> creates a single journaled preset that is used only as the default at
> startup. In methods 1 and 2 everything that was not explicitly saved
> before shutdown is lost.
>
> My current main fx processor is an ensoniq dp4. It is the only piece of
> digital hardware in my studio that uses method 3. Everything else uses
> methods 1 or 2. From my experience, method 3 is far superior to methods
> 1 and 2.
>
> Tom
>

-- 
       \|/
      <@ @> Stefan Kost  private                   business
+-oOO-(_)-OOo------------------------------------------------------------- - - -  -   -
|        __    Address  Zwenkauer Str. 24         HTWK Leipzig, Fb IMN, Postfach 300066
|       ///             04277 Leipzig             04277 Leipzig
|  __  ///              Germany                   Germany
|  \\\///      Phone    +49341 3910483            +49341 30766101
|   \__/       EMail    st_kost_AT_gmx.net           kost_AT_imn.htwk-leipzig.de
|              WWW      http://www.sonicpulse.de  http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri May 31 2002 - 10:13:23 EEST