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
pgp2Aa1gspXF6.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
