Re:

[David Griffin]

>> The other thing I noticed is that having the 'param' type be a float
>> is very limiting. I'd like to get more info back from the widget than
>> merely a number. Ideally, I'd like the entry widget to return a char*.
>
>Do you mean some kind of facility where arbitrary command strings can be
>passed to the plugins? I can see how that would be useful, but I prefer
>the MIDI approach of named parameters and encoding commands into numbers
>delivered to certain "ports", which you can do quite a bit with.
>
>The whole point of the parameter/type system in Octal is to impose
>structure on communication between plugins and the host and
>user---thereby enabling a sequencer and GUI that can edit any aspect of
>a plugin.
>
>If everything is just strings without consistent structure, well yes we
>can store and send strings at the right time, but how do you edit them,
>visualize them (like parameter sweeps/curves)? The plugin writer then
>would have to choose between either writing an extension so that the
>sequencer knows about the new data type (this would be especially the
>case with your void* idea) or just not letting anyone sequence that
>parameter or port, in which case implementing it is a waste of time (try
>restoring a plugin's state between performances if some of its
>parameters aren't sequenceable.)

i admit that by the time your response had come back, i had ruled out
a void* for exactly the same reasons you mention - that the core would
have a hard time dumping and restoring the state of a plug-in that
contained arbitrary data types.

but let's go back to char* for a second. one thing i see char* being
useful for are for holding filenames. there's currently a machine on
sourceforge called pwgen that loads wavetables from files. the way it
loads wavetables is it looks for files named '*.oot' in the current
directory. but it would be cleaner (you don't have to have all the
wavetalbes in memory) and nicer (the wavetables could live anywhere in
the filesystem) if you could load one wavetable at a time by making
one of the parameters a filename.

another example. i've written a machine (will upload soon) that plays
sound loops, like old-fashioned tape-loop effects. the sound-loops are
intended to be arbitrary and reside in files. now, i can hard-code the
filename into the machine (which is how it works now) or i could have
the filename for the loop be a parameter and editable (and
sequenceable). of course, you'd need the entry widget functioning for
it to be editable.

nor would using a char* destroy the consistency of any current
machines. for all current machine parameters, you'd simply call atof()
on the char* to convert it into a float. (and on the core side, you'd use
sprintf() to turn the float into a string.) for most machines, that's all
you would need. but if the machine knew that a parameter was something
more than simply a string representation of a float, it could do with
it as it needed.

griffin