8 Jul
2016
8 Jul
'16
5:26 p.m.
On 07-08, Rui Nuno Capela wrote:
uh oh... maybe it's the distrho implementation
lv2_state to blame? maybe a
lv2::string is being reported (by disthro), and then qtractor's xml parser
(qt xml/dom) just escapes the state as bland xml::cdata aka. POD (plain old
data)?
I checked with falktx about the distrho side of things before posting,
and it should return an unescaped string which contains the xml state of
zyn.
I'd expect your guess about the qt xml/dom to be correct.
otoh. zynaddsubfx is a dang complicated contraption...
i doubt it will ever
have any subset (yes, tiny subset) of parameters that may have any
reasonable automatable capabilities, besides, of course, the nominal ones:
So,
it's not going to have a 'fixed' set of parameters which can be
modulated/automated/etc.
Last time I counted the total possible parameters given the default
number of parts/kits/voices/etc there's a bit over 6,000,000 parameters.
Think about how big of a .ttl that would be :p
The way that MIDI learn works is:
1. you select one of these many parameters
(Middle click or CTRL+right click in the fltk/ntk UI)
(if you're in a version where this doesn't lauch correctly use
zynaddsubfx-ext-gui osc.udp://localhost:PORT)
2. you send zyn an unbound MIDI CC
3. zyn creates an internal mapping from MIDI CC -> internal parameter
This isn't visible as a standard lv2/vst/etc parameter, so it's quite
non-standard in that sense, but IMO it's a reasonable solution given the
scope of zyn.
So, remove your doubt and enjoy the non-standard solution to this problem.
--Mark