On December 9, 2012 01:09:13 PM Dan MacDonald wrote:
> I've just had a quick play with the latest, vestige-using svn and I was
happy to see Noizemaker is working now and I can select presets for it without
having to open its plugin window so good work there Tim!
>
> One of the biggest showstoppers for the VST support now seems to be (easy)
parameter automation. If I add Aspect or Noizemaker to a session, assign it to
a MIDI track, open its piano roll then click on the CTRL icon at the bottom of
the piano roll I get the MIDI controllers menu and within that there is
'Instrument Defined' with an 'Add' sub-menu that does nothing currently. With
both of these synths I would expect to see 100+ parameters I should be able to
choose to automate but this doesn't seem to be supported yet.
>
> I am looking in the right place here aren't I Tim? I expect its something
you've not added yet right?
>
> OK I think I've given poor Tim enough to chew on for the next week at least
now! :D
>
> Thanks Tim!
>
[Deep breath] Sigh. OK Read carefully, here's da situation wif da automation:
Short answer: You want the 'Automation' column in the Arranger Track List.
There you can assign midi controllers to the synth's parameters, as well as
any rack effects the track may possess.
Long answer (grab a coffee): If you add a DSSI synth, you will notice that
the piano roll midi controller graphs DO list an entire series of available
midi controllers for the synth.
However, /that/ simply does the same thing as the 'Automation'
Track List column. It takes the incoming midi stream and /converts/ it
to a floating point stream which modifies the synth's parameters,
just as if you adjusted a slider or knob or switch etc.
(Keep in mind the 'Automation' Track List column was added quite later on.)
But there's a difference with DDSI: It supports an actual assignment scheme,
which is *crucial* for reporting to the user what is actually assignable !
Otherwise you stuck reading from a 'cheat sheet' in the manual.
VST does *not* have a scheme (at least <= 2.4 dunno 'bout 3) AFAICT.
It is the reason when you try for example the fabulous XSynth DSSI
(try it!) the midi controller graphs list /two/ additional midi controllers:
5 Glide Rate, and 8 Oscillator Balance. These are /not/ floating point
audio 'parameters' like all the others listed - these are true integer midi
controllers supported by DSSI. Smart, eh? It let's me report them to users.
Now, about the others, the 32NF0 and so on, /these/ are floating point
parameters which *I* created to map to the parameters, arbitrarily assigning
beginning at NRPN 14bit #0 (that's what the NF means), simply because
we had no /other/ mapping scheme at the time, so to get folks up and running.
But one problem is that the DSSI synths themselves can respond to certain
controllers and not even inform DSSI ! Thus we have no way of knowing
whether 99% of DSSI synths support Pitch Wheel or not for example,
because they don't report it - they just 'silently' accept it.
OK, so about the VST: I've not done this arbitrary 32NF* assigning (yet)
because we have true parameter automation midi assignment in the Track List.
However, the graphing is a bit weak but getting better.
And yes I realize it is desirable to have the midi graphs as well.
Yeah been pondering it for a while (before VST).
When we have a midi controller stream which is assigned to an audio parameter,
should we
a): record it only as audio automation graphs (midi data is lost!)
b): record it only as midi automation graphs (ironically converted as audio
parameters anyway!)
c): both
Yeah was thinking, should I just dump the incoming midi stream 'as is' into
the midi graphs. Advantage is that the true original midi data is preserved.
OK now here's the real problem at the moment:
Waaay back at the front of the midi *input* driver side, we (blush) actually
have *no* support for RPN NRPN controllers, only regular controller7 CCs !
You can /draw/ the graphs but there's no way to /record/ em !
Been studying the situmutation: I /could/ quickly add support
(it involves remembering 'current' (N)RPN H/L param numbers and so on)
but it pays no regard to what type of instrument is sending and whether
the numbers should be interpreted as RPN or NRPN for example.
A more elegant solution is... drum roll please...
INPUT Instruments
In addition to the output instruments that we have now.
That is, you tell MusE what kind of instrument is supplying midi input -
patches, supported (N)RPN controllers - the whole picture, and *then*
we'll talk, because I dunno if I can trust the numbers you're sending me!
He he...
** Before I forget, someone once asked about DAISY CHAINING MIDI.
I replied that it appears do-able with our Jack midi devices but not ALSA.
Yeah been pondering this. I think it would be relatively easy to change MusE
from PER-PORT instruments to PER-CHANNEL instruments.
And be shown in the midi track info. (Yeah!)
That way the physical devices in the single midi 'chain' could be set to
different patches and so on.
I hope this would help solve the problem.
But I wondered about SYSEX support - how does one send SYSEX messages
(especially the 'generic' ones GM ON etc) to these individual devices?
SYSEX don't have channels. There /is/ a defined midi meta to set the
channel for that kind of thing but that's only midi files, not real-time.
Cheers. Tim.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
