On 06/17/2015 10:38 AM, Gerald Mwangi wrote: No I didn't. It's a demo from Yamaha, but I think it sounds better in setBfree :) My favorite part is around 40 sec - the modeling of the percussive key-clicks during the glissando, and the Leslie kicking in 10 sec later. Anyway, if someone feels inclined, it'd be great to have more demo songs to include on the website and/or links to music played/recorded with it. Please shoot me an email or simply reply here. Let there be music! robin

On 06/17/2015 06:46 PM, Christopher Arndt wrote: The former. There are two parts to it: KB3X42_1.K25 is a preset to load into the keyboard and K2500.cfg has corresponding Midi-CC mapping for setBfree to control the drawbars for both manuals and the pedals. I don't own a Kurzweil myself and don't know the details, they were created by Jean-Luc Nest and IIUC the K25 preset is needed to map the midi-channels. For the setBfree part, you can load the .cfg either on the commandline setBfree -c /path/to/K2500.cfg or use the GUI, Shift+L then browse to the file or simply save it as $HOME/.config/setBfree/default.cfg best, robin

On 06/19/2015 01:52 AM, Christopher Arndt wrote: [..] Interesting. Does that mean that the setBfree's whirl emulation beats the Kurzweil Leslie, while the Kurzweil-B3 sounds more realistic than setBfree's tonewheel synth, or is this just /differently/ realistic? Is there anything notable that you would change in setBfree? One thing that B3 players regularly mention is that setBfree's drawbars are by default not [yet] like the real thing. Some of the stops (IIRC 3 to 5) are too soft. That's part of ongoing research and tweaks. Another thing are signal-leakages, they differ depending on age maintenance, custom wiring,... Those are configurable in setBfree and now also easily accessible. I don't have access to a B3 (nor a Kurzweil) to compare, but I heard from various people who do, that setBfree is very close to the real thing; assuming you mic it, of course. Nothing compares to sitting next to a real Leslie :) Either way, it's a nice option to have. Modular setups are cool, and more diversity in sound is a good thing. Do you think it makes sense to include those files with the upstream setBfree? The PK3 may make sense, but not all distros ship Carla. best, robin

Am 19.06.2015 um 04:54 schrieb Robin Gareus: The Carla setup is only necessary to map a MIDI CC to the Leslie slow/fast switch. If there is a way to do the same with the standalone version or with e.g. jalv, it wouldn't be needed. BTW, one suggestion for improvement I have would be to change the order of the options of the Leslie motor control switch, so that "both slow" is first in the list and "both fast" last. That way one could use a MIDI CC, which toggles between values 0 and 127 to change between slow and fast, which is the operation which is used most often during playing. As it is at the moment, you need to configure your MIDI controller so that it toggles between 64 and 127, which is unusual. Chris

That would be cool. Then one could at least use something like mididings to control the standalone version or the plug-in running in jalv via MIDI, by using midings to bridge between MIDI and OSC. Chris

On 06/19/2015 07:19 PM, Christopher Arndt wrote: OK. I was referring to the sound, but feedback on the GUI is fine, too. No you can't currently skip the animation, but you can directly jump to all the items available on the rear-panel via keyboard shortcuts. Press '?' or click the button top left with a "?" for a list of available keyboard shortcuts. The speed (chorale/off/tremolo), yes, you can. Press 'm' to view current midi CC assignments. Ctrl+middle-click (same as ardour) to re-bind. Other Leslie parameters can currently only be bound to midi-CCs using a text config file (see setBfree --help or `man setbfree`). There's a subtle trick: ctrl+middle-click on the left control (separate horn/drum, 8 possible steps) vs right lever (linked: 3 steps). The On-Screen-Dipslays show that. Both are however currently fixed CC-value maps (no foot-pedal-friendly toggle/cycle). The help screen is terse but it is mentioned as "(Re) Assign Midi CC". best, robin

Thank you Robin! great work. Nowdays I am using carla plugin host with calf organ. It has advatages: - carla itself can save the preset of calf organ - I can with OSC change the parametres of organ It will be great if it will be possibile also with setBfree. have a nice day. fero

Am 21.06.2015 um 17:44 schrieb Robin Gareus: Carla can load LV2 presets. It can not save them yet. But of course it saves and restores plug-in states, also for LV2 plug-ins. I'm not sure I understand or agree with the reasoning behind this. The advantage of using an LV2 plug-in is having a unified interface to set plug-in parameters and save their state. Mapping MIDI to plug-in parameters should ideally be the job of the LV2 host (though, if the plug-in also has a standalone version, I guess it is easy to implement internal MIDI handling as well). Chris

On 21-06-2015 19:03, Robin Gareus wrote: LV2 can report the initial/wanted CC value. If your control port has something like this: [ a lv2:ControlPort, lv2:InputPort ; lv2:index 2; # etc midi:binding [ a midi:Controller ; midi:controllerNumber 1 ] ; ] . I guess in LV2 presets the mapping could be described in the same way, example: [ lv2:symbol "attack" ; pset:value 0.5933333 ; midi:binding [ a midi:Controller ; midi:controllerNumber 11 ] ; ], With the initial midi mapping included in the plugin ttl the hosts will know what to do. Carla implement this (and also an old lv2 spec for the same thing). No idea about other hosts. see http://lv2plug.in/ns/ext/midi/#binding for more details. tbh I think you're doing it wrong. You want to automate some plugin parameters, that's fine, but that should be done on the host-side! Because you do this inside the plugin and LV2 says you can't change your plugin input ports, it means you can't export those parameters as control ports. If a midi-cc event on the plugin side triggers some control port update, the host cannot know about it. Carla already includes the midi-cc configuration as part of a saved preset, and when that preset is loaded it will restore the cc mapping. (it does not export presets to lv2 format yet though) Carla will not load the midi:binding [] inside a lv2 preset right now, because this is actually the first time I though about it... Anyway, is there a real reason for setBfree to not have its parameters exposed as control ports? If you need to have presets that include midi bindings you can do like I posted above. BUT, again, I believe doing the midi-cc mapping on the plugin side is the wrong approach.

On 06/21/2015 08:07 PM, Filipe Coelho wrote: [..] This is indeed the main reason why they can't and won't be exported as control ports. Why not? The official midi midnam spec is precisely for that case. There are various hosts (commercial and otherwise) that support it already. That's Carla specific isn't it? Knowing you it'll only take a day or two now until it does :) There are way to many of them for it to reasonably work. Particularly in Carla which sends port_events for all ports in every cycle regardless if the value has changed. This does not scale. It also does not allow for midi-feedback. Loading a program (which is part of a preset) in setBfree sends updates back to the control surface. eg. load MIDI-program #1 -> drawbars on the organ move to reflect this change. Likewise for changes using the GUI. As you already mentioned a plugin cannot modify its own control inputs and a host cannot reasonably manage [plugin specific] programs (partial subsets of the whole config). So the way forward is to use meaningful messages. And currently the only set of specs that satisfies the requirements for this is MIDI. Sadly LV2 is not there, yet. If you have an alternative solution for this case, I'm all ears. Agreed, the idea is to eventually delegate mapping it to the host. ciao, robin

Hi Filipe et al, Maybe we should continue this lv2-dev (CCed) or LAD. You raise some interesting points. On 06/21/2015 11:16 PM, Filipe Coelho wrote: In an ideal world, yes, but it is unrealistic to demand from all host to manage complex one-off plugin specific relations. For simple synths fine; but understanding which parts and aspects of a synth specific state can be part of a [midi-]program, perform atomic reloads and manage transitions is not the hosts job. I think it's a geeky pipe dream, but a nice one, I admit. Only the plugin "knows" what happens if the state changes and hence only the plugin should change it if asked to do so by the host. The same also applies to simple things such as "Bypass" as we've discussed at LAC. IMHO a plugin host is literally just a host and not an omniscient dictator in control of all parameters. We may have to agree to disagree on that. Exporting all control ports is not an option for the case at hand. Check how many floats pointers one reasonably use on a modern machine without significant overhead compared realtime processing (say 128 audio samples). As opposed to audio-processing, you can't unroll loops nor use SIMD, MIMD instructions there: Set value in host; dereference pointer in the plugin; check if it the value has changed and is within bounds. Then compare that to the fixed cost of parsing a 3 byte MIDI message or a 32 byte LV2 Atom which conveys the same information. indeed. There's been great progress on the LV2 front. Regular as in "all float control ports"? no. Regular as in "using LV atom messages"? yes. right, except via http://lv2plug.in/ns/ext/midi/ Nor do I. Yes, that would also be against the LV2 spec. There likely won't be any control ports for setBfree and it will be only LV2 Atom message passing between host and plugin. Said Atom messages are currently MIDI (which a host could understand) and the plan is to eventually migrate fully to LV2ey messages (pending a host can generate MIDI from it to send to an external control surface). There are currently few hundred thousand internal parameters which can be dynamically modified (using a single command) and a few hundred thousand more which require re-initialization. The relation between those parameters is easy enough to do with some basic maths and loops, but teaching a host to learn "Go from current-state to Program #15" is close to impossible. There is a specific transition. One possible solution is to create a "simple version" that exposes a subset of meta-controls which can reasonably be managed by any host. A missing link with that option is to provide feedback to the control surface. As was succinctly mentioned earlier in this thread: The first thing most B3 players do is open and re-wire the instrument :) setBfree has the goal to preserve that spirit of the original instrument. The number of exposed controls has increased over time and that trend will continue. I did make a list back in 2012 when creating the setBfree LV2 plugin. Most of this went into http://lv2plug.in/ns/ext/midi/ v1.6 and 1.8 later that year into http://lv2plug.in/ns/ext/patch/ since. What's missing is host-support, esp. for the latter. The vast majority of settings in setBfree are instrument properties and LV2:Patch is ideal for the case at hand. All internal controls already have identifiers suitable to become a patch:subject (which can also be used as OSC path). Note that the setBfree LV2 plugin is still a side-project that came to be because I like LV2 and think it's the plugin standard that sucks least. Migrating all of setBfree to LV2 properly is the long-term plan and moving slowly. The priority here is *not* to provide a fully fledged LV2ey LV2-plugin to musicians *today*, but to get it right in the long run. The main thing that's really missing are man-months. The LV2 specs are sufficient already. Ardour4 recently gained initial support for LV2:Patch, but it's really only David and me working on this and we're both not available full time. Will C. (who manages setbfree.org and got permission to open-source beatrix in the first place) teaches High-school kids to hack and build organs using RPi, they won't be using a LV2 host to do so. He's also interested in people playing it live and most people who do prefer the standalone jack app. I am really glad that the MOD went with ingen which also has most of infrastructure already in place. Does your CPU share that opinion as well? :) Display is the smaller problem. The case for custom GUIs is a proper layout, sensible control granularity and behavior. nice. Prospective search would indeed be great at least to look up parameters for mapping and automation. Are you going to implement this in Carla? I doubt that it's a software limitation. Checking a few thousand float control-ports for every 64 samples of audio strikes me as a bad idea. In setBfree by default, only 63 controls are mapped, but it's a flexible user-configurable map (not 1:1 port <> param). The complete set of available parameters is around a million. (As far as I know, only ZynAddSubFx is /worse/. IIRC it has somewhere around 36M params). Exposing them all directly would be insane and a nightmare for users to boot. Hence the idea is to use properties which can be queried and set on demand. LV2:Patch also allows a plugin to transition the state and acknowledge that some particular request has been processed successfully. How practical this will turn out in the real world remains to be seen but I think that's currently the best option. ciao, robin

On 06/22/2015 08:48 PM, Rui Nuno Capela wrote: likewise :) [..] one word: automation If we allow plugins to change their own input, that opens a can of worms: From conflicting values, feedback loops to potentially different host behavior and unreliable output. Hence I made the case for simply not exposing *all* controls parameters (as some people have asked) as standard float control ports. It's as simple as: no control-input, no cry :) The plugin can do as it sees fit. maybe. A float pointer is perfectly fine for many plugin controls, and it also provides backwards compatibility to LADSPA. What I think is wrong, is LV2-users and LV2 host-authors expecting all plugins to export all their controls as POD float. LV2 offers much better mechanisms. As far as I know, all major plugin standard have that restriction. It's important for being able to reproduce the same output, given the same input. A Plugin is a Mealy machine (output depends on input and internal state). It has, hasn't it? Just don't use old LADSPA-like float-pointer control-ports, but use messages to set/modify the internal state. The most common denominator for messages is currently MIDI, but as is OSC is up and coming as is LV2:Patch. See recent LV2:Patch:Set file-name support in liblilv-SVN, jalv and Ardour4. That allows hosts to tell plugins to load some specific file (eg an IR or a sample) at a given time. If and how that happens is left to the plugin. It only took 3 years from the first plugin that supported it until host support showed up :) best, robin

On 06/22/2015 10:54 PM, Rui Nuno Capela wrote: [..] of the parameter in question. If you have a manual fader connected to a control input and the plugin itself changes the value, yes the host could just update the fader. Would be a fun game to watch, though: Plugin pushes the control down, the user pushes up. Might be entertaining to make a contest out of it :) but for serious pro-audio, really? What should happen if the user specified an automation-curve that the plugin should follow? ..and now the plugin comes along and /rewrites/ that curve? mmh. maybe I'll have to eat my words.. So does LV2. IIRC VST uses a setParameter() and getParameter() methods. No shared memory. Anyway, VST is a mess of 90's engineering. The sooner we forget about it, the better :) AU has a clear separation of Scope. Input, Output and Global which is usually also an input, but there are additional properties for access: write/read or In/Out. For the scope: Output is "0" Input is "1" you can't bit-flag combine them. However the is the concept of AUDependentParameter: a "parameter whose value can change in response to a change in its parent metaparameter" nice, ey?! There are also SetProperty() and GetProperty() and GetPropertyInfo methods in AU, one can set up Listeners (callbacks for changes) and you can also pass around PropertyList and Dicts.. It's not unlike to passing LV2:Patch (property) messages in an Atom Sequence around in the LV2 world or a LV2 plugin sending out notifications to the host. LV2 Atom messages are also using shared-mem. I don't catch that drift. Nobody suggested to process separate the DSP in LV2. It simply does not scale. [..] Yes, and that's already part of the LV2 specs. There are various types available. e.g LV2_Atom_Int. Vocabulary and semantics already exist. [..] It can be anything really, including float. and also provides means to do that sample-accurately (if needed). It works both ways. LV2 Midi output is one example where many hosts already parse LV2 Atoms generated by a plugin and take action accordingly. It also works for float or ints and vectors, but there is currently no plugin that uses it that way. Currently the only notifications that some hosts (Ingen, jalv and Ardour, soon also Carla) intercept is filenames (eg plugin restores state and notifies host about changed file). best, robin

On 2015-06-23 01:21, Robin Gareus wrote: i guess i've been saying that it *should* be something similar to the port_event() and write_function() methods which are for the plugin <-> UI interface, but then for the plugin <-> host interface, which there isn't but shared-mem (de)referencing. yes, there's also the lv2atom::eventTransfer mechanism, but this time it's a host <-> UI interface; again, "we" need something similar for the plugin <-> host interface, especially to let the host acknowledges that the plugin changed or wants to change one of its own parameters. look, for instance, there are a world of plugin instruments out there that supplies its own presets, addressable through MIDI bank_select+program_change, which are channel messages, so it should only affect one of the plugin parts (if multi-timbral) and NOT the entire and complete plugin instance state. in response to this kind of MIDI input the plugin should or even must change one or more of its own parameters besides other internal state specific to the part being selected. note that all of this often occurs *without* UI intervention (or proxying) as the UI might well be not visible at all. now, if the host doesn't get it properly notified it will assume the previous or even (re)set to its own version of the parameter values, with unpredictable consequences and most probably NOT what the incoming MIDI PC message meant in the first place (changing an instrument part preset or program). of course this also applies to a plugin's own MIDI CC configuration, binding or assignment. again, there's a vast multitude of plugins which have it as on their own business, that is, it's not necessarily a host's provided feature; a plugin's MIDI CC real-time response most probably goes to one or more of its own parameters, so they will change them as sees fit and to its own purpose--the host *must* know or listen that this event is occurring and react accordingly. alas, in LV2 there's no standard defined way to do just that. iow. LV2 dictates that all plugins must not ever alter their own parameters (input control ports) and thus delegate all MIDI CC, PC and any other controllability features and support into host's shoulders. and that's a shame if it stays this way. cheers -- rncbc aka. Rui Nuno Capela

On 06/23/2015 02:37 PM, Robin Gareus wrote: ... i still think that a simple standard defined message for a plugin to tell its host the following: "-- i've made some changes onto my own internal state, including some, if not all of (my) parameters (aka. input control ports), so please scrap all your current view state of me from this moment on and get it all re-freshened up, will you? btw. you can also opt to set your session dirty flag, as for saving my (partial new) state later on." would solve a lot of grief i suppose. my2c -- rncbc aka. Rui Nuno Capela ps. once upon a time, me and falktx poked drobilla about this, while during this latest lac2015@JGU-Mainz. iirc. all we nodded in agreement :)

Just want to say I'm finding this thread compulsive reading, and very informative :) -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Sun, Jun 21, 2015 at 10:31 PM, Robin Gareus &lt;robin(a)gareus.org&gt; wrote: I must confess that I'm guilty of that, too -- my faust-lv2 and faust-vst plugin architectures for the Faust programming language all do their own midi cc processing (according to the corresponding hints in the Faust program), even though in this case all the control values are also exposed as control ports (and the two work in concert, of course). In principle most of this could (and should) all be done on the host side (although there might be special circumstances under which some processing needs to be done on the plugin side). But right now you can't even be sure what facilities the host offers for that purpose. Does it support the midname spec? Does it take corresponding hints from the LV2 manifest? Or will it simply pass on midi cc's if there are midi input/output ports? Etc. I admit that I'm confused by the state of affairs in this department, and I'm probably not the only one. Sounds like a great topic for discussion at next years' LAC. :) Albert -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef(a)gmail.com WWW: https://plus.google.com/+AlbertGraef

- for some unknown reason I can't change the parameters in Carla (I can't see them..) - I did't know that Carla can save also foo-yc20 presets -- is is also very cool organ - I am learning everyday something new. great! - Carla is making for each parameter its own OSC address so thats the way I am sending data to calf organ - I play Calf organ on midi keyboard. OSC for tuning the parameters I am always using on soundchceck before concert - autoplay some midi & tablet + TouchOSC to control params from distance to tune the sound before performance.. thank you Robin. 2015-06-21 15:44 GMT+00:00 Robin Gareus &lt;robin(a)gareus.org&gt;rg>: -- Fero Kiraly pianist, musician, teacher www.ferokiraly.com www.cluster-ensemble.com

On 06/18/2015 01:13 AM, Christopher Arndt wrote: Nice. Thank you very much for confirming this. Yes it is. Current git-head is v0.8.0-8-g90e925d it looks like you got very lucky with 0.8.0-8... At a quick glance, it looks like you've missed cairo (for the standalone leslie GUI) but that may be implicit via pango/pangocairo on Arch. Is there a list of files that will be installed after compilation? For comparison, the contents of the debian package is http://paste.debian.net/236269/ The PKGBUILD looks just fine. Good job including the man-pages and .desktop file. (There should really be a `make install-man` target as part of `make install`. Oh well, 0.9 will have that.) setBfree 0.8.0-8 goes live on 08/08! best don't touch the package :) Cheers! robin

Am 18.06.2015 um 03:56 schrieb Ralf Mardorf: I think Robin meant this: $ pacman -Qlp setbfree-git-0.8.0.8.g90e925d-1-x86_64.pkg.tar.xz setbfree-git /usr/ setbfree-git /usr/bin/ setbfree-git /usr/bin/setBfree setbfree-git /usr/bin/setBfreeUI setbfree-git /usr/bin/x42-whirl setbfree-git /usr/lib/ setbfree-git /usr/lib/lv2/ setbfree-git /usr/lib/lv2/b_overdrive/ setbfree-git /usr/lib/lv2/b_overdrive/b_overdrive.so setbfree-git /usr/lib/lv2/b_overdrive/b_overdrive.ttl setbfree-git /usr/lib/lv2/b_overdrive/manifest.ttl setbfree-git /usr/lib/lv2/b_reverb/ setbfree-git /usr/lib/lv2/b_reverb/b_reverb.so setbfree-git /usr/lib/lv2/b_reverb/b_reverb.ttl setbfree-git /usr/lib/lv2/b_reverb/manifest.ttl setbfree-git /usr/lib/lv2/b_synth/ setbfree-git /usr/lib/lv2/b_synth/b_synth.so setbfree-git /usr/lib/lv2/b_synth/b_synth.ttl setbfree-git /usr/lib/lv2/b_synth/b_synthUI.so setbfree-git /usr/lib/lv2/b_synth/manifest.ttl setbfree-git /usr/lib/lv2/b_whirl/ setbfree-git /usr/lib/lv2/b_whirl/b_whirl-configurable.ttl setbfree-git /usr/lib/lv2/b_whirl/b_whirl-presets.ttl setbfree-git /usr/lib/lv2/b_whirl/b_whirl.so setbfree-git /usr/lib/lv2/b_whirl/b_whirl.ttl setbfree-git /usr/lib/lv2/b_whirl/b_whirlUI_gl.so setbfree-git /usr/lib/lv2/b_whirl/manifest.ttl setbfree-git /usr/share/ setbfree-git /usr/share/applications/ setbfree-git /usr/share/applications/setbfree.desktop setbfree-git /usr/share/doc/ setbfree-git /usr/share/doc/setbfree-git/ setbfree-git /usr/share/doc/setbfree-git/AUTHORS setbfree-git /usr/share/doc/setbfree-git/ChangeLog setbfree-git /usr/share/doc/setbfree-git/README.md setbfree-git /usr/share/doc/setbfree-git/b_synth.png setbfree-git /usr/share/doc/setbfree-git/b_whirl.png setbfree-git /usr/share/doc/setbfree-git/setBfree.png setbfree-git /usr/share/doc/setbfree-git/signal_flow.png setbfree-git /usr/share/icons/ setbfree-git /usr/share/icons/setBfree.png setbfree-git /usr/share/man/ setbfree-git /usr/share/man/man1/ setbfree-git /usr/share/man/man1/jboverdrive.1.gz setbfree-git /usr/share/man/man1/setBfree.1.gz setbfree-git /usr/share/man/man1/setBfreeUI.1.gz setbfree-git /usr/share/man/man1/x42-whirl.1.gz setbfree-git /usr/share/setBfree/ setbfree-git /usr/share/setBfree/cfg/ setbfree-git /usr/share/setBfree/cfg/K2500.cfg setbfree-git /usr/share/setBfree/cfg/bcf2000.cfg setbfree-git /usr/share/setBfree/cfg/cx3.cfg setbfree-git /usr/share/setBfree/cfg/default.cfg setbfree-git /usr/share/setBfree/cfg/fartybass.cfg setbfree-git /usr/share/setBfree/cfg/osc-bassy.cfg setbfree-git /usr/share/setBfree/cfg/osc-middy.cfg setbfree-git /usr/share/setBfree/cfg/osc-noxtalk.cfg setbfree-git /usr/share/setBfree/cfg/osc-sawtooth.cfg setbfree-git /usr/share/setBfree/cfg/osc-scoop.cfg setbfree-git /usr/share/setBfree/cfg/osc-square.cfg setbfree-git /usr/share/setBfree/cfg/osc-trebly.cfg setbfree-git /usr/share/setBfree/cfg/osc-triangle.cfg setbfree-git /usr/share/setBfree/cfg/osc-xwave.cfg setbfree-git /usr/share/setBfree/cfg/oxy61.cfg setbfree-git /usr/share/setBfree/cfg/whirl-mellow.cfg setbfree-git /usr/share/setBfree/cfg/whirl-sharp.cfg setbfree-git /usr/share/setBfree/cfg/whirl-x100.cfg setbfree-git /usr/share/setBfree/pgm/ setbfree-git /usr/share/setBfree/pgm/default.pgm setbfree-git /usr/share/setBfree/pgm/popular.pgm yaourt will show you this list on request after you built the package from AUR. Chris

On Thu, 18 Jun 2015 03:26:27 +0200, Robin Gareus wrote: $ pacman -Qi pango | grep On Depends On : libthai cairo libxft harfbuzz

Am 18.06.2015 um 01:13 schrieb Christopher Arndt: I update the package with some improvements: - Add missing jack dependency - Install all icon sizes from *.icns files into hicolor icon theme - Add desktop file for x42-whirl Chris