> > > Is it possible to have more than 16 synth plugins? If so, how?
> > Only by changing the code and recompiling, at the moment. Yes, it woul=
> > nice to do something about that.
> Thinking what? Configurablize it so it's adjustable in real time, what?
> Where does this really come into play? At doc creation time? Would chan=
> it arbitrarily in the middle of a composition be problematic? What about
> changing it and then having to save and re-load for the change to take
> I ask because it sounds like a very piddly thing to configurablize, but I=
> little about the potential ramifications of doing so. No use going off t=
> it only to find it breaks things I didn't anticipate.
Well, I am investing some time in trying to use RG sequencing orchestral mu=
For that I need acoustic sounds, i.e., fluidsynth and linuxsampler,
although I may throw in some synth stuff as well just for the fun of
I also need some way of remapping the midi input to the sequencer. For
instance, converting pitch bend into expression controller. Live.
Sure I can use RG + qmidiroute + qsynth + linuxsampler +... Working
like that means every time I open an existing project:
1) Firing up all the programs.
2) Load the configuration for that project at all of them.
3) Patch them together.
This is error prone and time consuming.
Of course there are things one might do to ease up that task.
1) First that comes to mind is a shell script. Geeky. Will work for
me, but it won't attract many non programming users.
2) Convincing LADs to adopt LASH. http://www.nongnu.org/lash/ Not
likely to happen in a near future, but Juan and Dave have some very
good points there.
3) Building all the necessary tools in a monolithic application. We
all know why this is stupid.
4) A plugin system so one application is "master" and holds the
configuration for the rest of apps. VST, DSSI, MESS, whatever. This
has proved successful in the Windows & Mac world.
Hey, I left the good one for the end! Sneaky, aren't I? Yup, as a
user, I for one would like Linux apps develop in the VST-like
interoperability direction. As far as RG is concerned, I'd rather see
it improving in the session management department (the Studio, as you
name it) than in the interaction between music notation and midi
sequence. For that problem I find more realistic developing a
"configurable score to midi compiler" approach, like Sibelius(tm).
Retaking the discussion of synth plugins in RG, I think:
1) Hardcoding is generally a Bad Thing (tm).
2) Hardcoding the max synth plugin number in a file named AlsaDriver.h
and then again in another place without #defining it might not be the
best way of attracting fellow developers ;-)
3) If you set too low a limit you cripple your capabilities. If you
set it too high, you waste resources and, worse, clutter your GUI. A
dynamic approach "alla cubase(tm)" while the playhead is stopped seems
If you hesitate to make this improvement because you consider it non
important and don't know how this may impact your software, well,
that's your rightful decision to make and just hard luck for me. From
what I experienced about trying to find my way in RG sourcecode, I
don't think I am doing it myself, too.
Please take this as constructive criticism and not even suggestions,
but well meant wishes, right? Talking is cheap, coding is hard and
documenting is boring. I have contributed some fixes to other Linux
projects (and would be happy to do so for RG) and they are not better
off in the friendly code department.