From Buzztard

Plugins usually just announce a list of parameters, along with bounds and the parameter type. This is not enough to create a good user interface from. It is sufficient for a bunch of sliders, but thats it. What is missing here is information of parameter relation and purpose. Further often parameter have not very descriptive names. So it might be useful to overide the label.

The idea is to equip plugins with additional information, e.g. in the form of qdata blobs on properties. Wrappers like LADSPA or BML could use external XML that gets converted to qdata blobs.

Right now we already do some filetering on the base of the GST_PARAM_FLAG_CONTROLABLE. Controlable params are those that the user can modify over time. The other params consist of editable settings and parameters that are used for internal purposes. Ideally we had another flag GST_PARAM_FLAG_EDITABLE to flag parameters for the non-realtime settings.

[edit] sources

[edit] ladspa lrdf

Steve Harris maintains the ladspa rdf project. We need to check if it could express all we describe below. Similar stuff is used in the followup project LV2.

[edit] heuristics

[edit] groups

We could use check if subsequent parameter-names beginn with the same string. If so the common prefix would be the group name and get dropped from the individual labels. Ladspa uses the Group/Param convention (Env/Attack, Env/Decay, ...).

[edit] own xml blobs

If we would use own xml, how could that look like?

 <layout category="">
   <group name="" role="">
     <param name="" label="" type="" role="">
   </group>
   <param name="" label="" type="">
 </layout>

Now lets look at the single elements.

[edit] layout

The category field is for a simple classification scheme of the machine. It would also allow to display a respective icon in the UI (lots of icons are in jokosher art repository.

[edit] group

Specifying Groups allows to put all those elements into a box and giving this a nice title. One could even add hide/show controls to the box, to allow folding it in to temporaily hide the controls (useful for large interfaces).

[edit] param

Describes a single param. The type is optional and can be {'controlable','editable'}. The role is used for the mapping within the groups role.

[edit] Roles and role mappings

The idea behin roles is to identify and name ui-patterns. Again lets start with an example. Imagine an audio synth, that has params for AttackTime, DecayTime, SustainLevel and ReleaseTime. That describes a classic envelope. Wouldn't it be better to let the user graphically edit it instead of giving him just four sliders. How would that look like in our XML?

 ...
 <group name="volume envelope" role="adsr-envelope">
   <role-mappings>
     <role-mapping param-name="AttackTime" role-param-name="attack"/>
     <role-mapping param-name="DecayTime" role-param-name="decay"/>
     <role-mapping param-name="SustainLevel " role-param-name="sustain"/>
     <role-mapping param-name="ReleaseTime" role-param-name="release"/>
   </role-mappings>
   <param name="AttackTime">
   <param name="DecayTime">
   <param name="SustainLevel ">
   <param name="ReleaseTime">
 </group>
 ...

The idea of the mapping is that the role defines it params and mapping assignes them. The plugin can name the params freely and so we need to correlate them somehow. All param elements that are not mapped should be layouted traditionally (above or below the role-interface object)?

[edit] Role catalog

We need to look at many synthesizers and effect units (virtual ones too), to build cataloge of useful patterns. This can also help to offer unit transformations in the UI (showing frequencies in 'Hz' and amplification as 'db').

[edit] Filenames & URIs

File selector popup button and drag'n'drop awareness for URIs. For filenames we need patterns and load/save mode.

[edit] Notation

Small piano roll for note values

[edit] Envelope

Graphical envelope editing. Envelopes can have different complexities:

• AR
• ADSR

[edit] Audio-Filter

graphical cut-off/resonance editing

[edit] Waveform/Osczillator selection

Add icons to waveforms (Sine, Saw, Sqr, Tri, Random/Noise). Leave unknown/unmapped entries blank.

[edit] Times

Some FX like Reverb, Echo, Multitap delay have several time based params. There it would make sense to edit them as markers on a timeline ruler.

[edit] Color picker

Choose a color (color wheel etc.)

[edit] Ratio

Instead of entering stuff as 0.25, it could allow notiations such as "1/4" or "25%".

[edit] More ideas

• state that a specific parameter value, disables other parameters (e.g. filter=0=off, disabled cut-off/resonancy)
• describe what units a parameter supports (frequency, ratio, time, ...). Then we could plug unit conversion and allow the user the use the units that suit him best.

[edit] Preset handling

Not all elements might support presets. If we use an interface we can make this optional. The preset-sidebar will then be disabled.

[edit] Buzz

Buzz shows a preset drop-down list at the top of the window and some buttons (Edit, Copy, Random, Help) example-window. Clicking on edit leads to another dialog where on can remove presets, give the current one a name and add it.

[edit] Buzztard

An alternative to this would be having a sidebar on the left, showing a list of presets (for machines with lots of presets also a tree is thinkable). The list will always have entries for current, default (reset to defaults) and random (generate random preset). When ever the user makes change selection goes to current.

Above the list we have a toolbar with Add and Remove buttons. Both buttons are disabled for current and random.

[edit] Idea 1

Below the list we can have textfield with the selected preset name and eventualy a preset comment (buzz-presets have a comment. If one wants to change a preset, select it, change it (selection goes to current), change the name and press Add.

[edit] Idea 2

When pressing Add a small dialog comes up, where the user can enter name and comment. We should have an Edit button to bring up the dialog for an existing preset (rename and/or change comment).