As hinted at in an earlier email (thanks for the help!), I have a new version of plugin~. It supports two new messages:
bind foo - listens for messages sent to foo-gain, foo-drive, etc. You can bind sliders, sssad objects, etc. to the same names and have everything just work.
bindscaled foo - the same, but translates messages from the 0-127 range into the range appropriate for that parameter (as defined by the ladspa plugin). If anyone has a pithier name for this message, I'm all ears.
I also went through and fixed several segfaults, mostly relating to messages sent without a plugin being loaded. Also, specifying a library file as a name without a full path now works whether or not LADSPA_PATH is defined.
I've posted my version at http://artdent.homelinux.net/publicsvn/plugin~/ . I've only tested it on Linux, as the SConstruct file needs some more work to be cross-platform and to integrate with the pd-extended scons scripts.
I'd be keen to see this get into the main svn repository (pending, of course, any fixes, improvements, etc). Should I make a patch file and add it to the patch tracker? Given the number of files involved, it might be easier to just check in the whole directory.
These extra messages have simplified some of my patches quite nicely; I hope they're useful to others in the same way.
(Also, side note to Thomas Grill: stupidly, I had been compiling flext from the (out-of-date) sourceforge repository. With the latest version from the correct repo, the autotools build works perfectly and does indeed require no more information than the path to the pd sources.)
On Tue, Sep 16, 2008 at 3:12 AM, Jacob Lee artdent@gmail.com wrote:
I've posted my version at http://artdent.homelinux.net/publicsvn/plugin~/ . I've only tested it on Linux, as the SConstruct file needs some more work to be cross-platform and to integrate with the pd-extended scons scripts.
Apologies - the url is http://artdent.homelinux.net/svn/plugin~/ .
Jacob Lee wrote:
As hinted at in an earlier email (thanks for the help!), I have a new version of plugin~. It supports two new messages:
bind foo - listens for messages sent to foo-gain, foo-drive, etc. You can bind sliders, sssad objects, etc. to the same names and have everything just work.
bindscaled foo - the same, but translates messages from the 0-127
as 0-127 is really only because of MIDI, i would suggest using "bindmidi" or "bindmidiscaled" (of "bind7bitbecauseofmidiandlongnamessuck")
in general i think we should use 0..1 for normalized ranges as much as possible (and as is used in the "mapping" library)
fgmasdr IOhannes
On Tue, Sep 16, 2008 at 3:23 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Jacob Lee wrote:
As hinted at in an earlier email (thanks for the help!), I have a new version of plugin~. It supports two new messages:
bind foo - listens for messages sent to foo-gain, foo-drive, etc. You can bind sliders, sssad objects, etc. to the same names and have everything just work.
bindscaled foo - the same, but translates messages from the 0-127
as 0-127 is really only because of MIDI, i would suggest using "bindmidi" or "bindmidiscaled" (of "bind7bitbecauseofmidiandlongnamessuck")
in general i think we should use 0..1 for normalized ranges as much as possible (and as is used in the "mapping" library)
Hmm. Besides midi, the advantage of 0-127 is that it's the default range for sliders. Of course, it's not hard to add [/ 127] and a send below the message, but at that point you might as well replace the division with a proper range conversion and add a [control foo $1(. Accepting the range 0-127 means requiring nothing more than named sliders.
The question might be, which is more common:
- bare graphical objects + midi inputs
- more complicated numeric manipulations, perhaps involving the mapping library.
In my case, it's the former. Does anyone else want to weigh in?
Another possibility is to accept messages like "bindscaled 0 127"; we'd still have to argue about the default, but the stakes would be lower.
Jacob Lee wrote:
On Tue, Sep 16, 2008 at 3:23 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Jacob Lee wrote:
As hinted at in an earlier email (thanks for the help!), I have a new version of plugin~. It supports two new messages:
bind foo - listens for messages sent to foo-gain, foo-drive, etc. You can bind sliders, sssad objects, etc. to the same names and have everything just work.
bindscaled foo - the same, but translates messages from the 0-127
as 0-127 is really only because of MIDI, i would suggest using "bindmidi" or "bindmidiscaled" (of "bind7bitbecauseofmidiandlongnamessuck")
in general i think we should use 0..1 for normalized ranges as much as possible (and as is used in the "mapping" library)
Hmm. Besides midi, the advantage of 0-127 is that it's the default range for sliders. Of course, it's not hard to add [/ 127] and a send
yes it's true; and i think it is the top of all the incorrect decisions in the design of the sliders (even worse than the built-in scale-distortion)
imho, a newly designed object should be able to handle legacy designs as far as "easily" possible, but it shouldn't be designed with legacy in mind. (or however one would phrase this - it's still early in the morning)
below the message, but at that point you might as well replace the division with a proper range conversion and add a [control foo $1(. Accepting the range 0-127 means requiring nothing more than named sliders.
indeed, but in order to name sliders one has to open the properties anyhow...
Another possibility is to accept messages like "bindscaled 0 127"; we'd still have to argue about the default, but the stakes would be lower.
i thikn that's a good idea. obviously i would vote for the default to be 0..1
fgnasdr IOhannes
On Thu, Sep 18, 2008 at 2:47 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Jacob Lee wrote:
On Tue, Sep 16, 2008 at 3:23 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Jacob Lee wrote:
As hinted at in an earlier email (thanks for the help!), I have a new version of plugin~. It supports two new messages:
bind foo - listens for messages sent to foo-gain, foo-drive, etc. You can bind sliders, sssad objects, etc. to the same names and have everything just work.
bindscaled foo - the same, but translates messages from the 0-127
as 0-127 is really only because of MIDI, i would suggest using "bindmidi" or "bindmidiscaled" (of "bind7bitbecauseofmidiandlongnamessuck")
in general i think we should use 0..1 for normalized ranges as much as possible (and as is used in the "mapping" library)
Hmm. Besides midi, the advantage of 0-127 is that it's the default range for sliders. Of course, it's not hard to add [/ 127] and a send
yes it's true; and i think it is the top of all the incorrect decisions in the design of the sliders (even worse than the built-in scale-distortion)
imho, a newly designed object should be able to handle legacy designs as far as "easily" possible, but it shouldn't be designed with legacy in mind. (or however one would phrase this - it's still early in the morning)
below the message, but at that point you might as well replace the division with a proper range conversion and add a [control foo $1(. Accepting the range 0-127 means requiring nothing more than named sliders.
indeed, but in order to name sliders one has to open the properties anyhow...
Another possibility is to accept messages like "bindscaled 0 127"; we'd still have to argue about the default, but the stakes would be lower.
i thikn that's a good idea. obviously i would vote for the default to be 0..1
fgnasdr IOhannes
I've updated plugin~ to accept messages of the form "bindscaled 0 1", with the two new arguments being the lower and upper bounds, respectively.
Right now the default for bindscaled is still 0 to 127. I'm highly inclined to leave in that way: if you're doing interesting things with the mapping externals, a couple of extra arguments to bindscaled is no big hurdle; if you're simply binding sliders to parameters, it's convenient for the defaults to just work.
Also, I tested building from the externals/build directory; it works once you add recv.c to the list of includes in externals/build/src/plugin~.c
(Also, side note to Thomas Grill: stupidly, I had been compiling flext from the (out-of-date) sourceforge repository. With the latest version from the correct repo, the autotools build works perfectly and does indeed require no more information than the path to the pd sources.)
Many thanks for the feedback, good to know! I think though that there are still problems with cygwin/mingw.
gr~~~
-
IOhannes m zmoelnig -
Jacob Lee -
Thomas Grill