Am 28.04.2016 um 21:06 schrieb Thorsten Wilms: I wouldn't be so negative as Thorsten, I think it's definitely an improvement over the old GUI, but I too think that it doesn't really address the real issue of a too cluttered interface. There are just too many settings and parameters and there is no real help from the interface in breaking it down into managable sections. Looking at the pictures, and not being overly familiar with Zyn, I'm not even sure, which page is for which synthesis engine at a glance. I do like the preset browser, though. I think every synth or effect software should have great preset managemen built in. Chris

On Thu, 28 Apr 2016 23:52:58 +0200 Christopher Arndt <chris(a)chrisarndt.de> wrote: Why code for this when the file system itself can organize the patches. That is, if Zynaddsubfx uses only files for the patches and does not have any embedded right in the software. If they're only files, then the patch browser becomes a plain file directory browser.

On Sat, 30 Apr 2016 20:30:44 +0200 Christopher Arndt <chris(a)chrisarndt.de> wrote: Hmmm.. not sure if that info is relevant. This said, looking at a real world case, u-he, if someone make a patch set, then he can organise it in the file system such as: Hollow Padsheaven 3 Bells & Ambients Soft & Warm Plucked Sweeps Leads & Dark Rythmic Yes, this is the "tags" notion that can be found for instance in Bitwig. That"s something else, and not sure, IMHO, if it os that much useful. I certainly do not use it yet. When I do something, I put the tag "mystuff" and that"s it, which can be translated to a filesystem easily.

On Sat, 30 Apr 2016 22:30:35 +0200 Louigi Verona <louigi.verona(a)gmail.com> wrote: Well, look at u-he. All their synths (on Linux) use a plain and simple file browser. The idea is that the filesystem provides the organization. Eg, for a patch set: Hollow Padsheaven 3 Bells & Ambients Soft & Warm Plucked Sweeps Leads & Dark Rythmic And these are found as-is in the filesystem. So on so forth. Simplicity, IMHO. But the synth must not embed sounds into its binaries.

On 04-29, Louigi Verona wrote: Thanks for taking the time to fill out the survey and going above and beyond. Agreed. You should have heard me tripping over my own words when trying to nail down the ideas of workflow and a user friendly experience when describing the whole project to a collogue... Agreed, I'm generally a resident of the Knob Universe and now I have the data to show that people who like to reply to the survey tend towards that side as well. So, this is something which is poorly communicated by the existing still mockup images and what I'm about to describe might not have been what the designer intended at all, but let me try to elaborate on this component. So, the region where the graph exists in can serve a few purposes in my opinion. It is a: 1. Detailed view of the data for the corresponding set of parameters 2. An interactive and graphical means of manipulating the parameters 3. A graphical view into how the currently running notes are affected by the parameters Point 2 might not make much sense, but consider the regions shown in http://fundamental-code.com/tmp/template-regions.png Effectively each orange, green, or purple region can change what the graphical representation in the red section is viewing. This means that you can view the current filter response, quickly see a LFO shape, or look at an envelope without changing to an entirely different view or tab. I think that's a pretty big improvement over the current solution which tends to involve growing new windows to see further into the data. Providing an interactive graphical view does also help with some of the musician's use cases IMO, but that impression may be ill founded. Point 3 for envelopes would look something similar to the sample position tracker that renoise has (basically a yellow bar which shows the phase/time position).. This might be overkill for a lot of these views, but hopefully with enough views into running notes it becomes more obvious what parameters are affecting that subtle element of a patch. A few mockups have been passed around the community in the past, though generally they tended to solve the problem with a greatly reduced number of parameters. That certainly helps when someone is in a musician mindset as you have pointed out, however it would be pretty off-putting to those who have access to their favorite parameters removed. (that's not to say that all parameters are useful, I just don't know which ones can be safely canned without notably breaking the app for existing users). At some stage I might analyse existing patches to find which parameters are essentially always at default levels and perhaps integrate some optional analytics into the 3.0.0 UI's demo to figure out what gets the most attention. So, other layouts are an option, but this one is the best one presented so far and it was generally well received for this facet when it was originally published. Once again it's the most efficient for the combined musician/sound-designer so far and it doesn't (relatively) have too much clutter or too much empty space. I'm not sure about the case of touch screens though. Based upon the responses so far it looks like at some point within development I'll end up purchasing a small touch screen so I can experience the same frustrations of users in that context. Yep, there is a *lot* under the hood to make everything resize nicely. Some of it is a little unconventional, but it seems to work well in the existing prototype. To a lesser degree, yes. This is where I see the simplified navigation, single window UI, easy MIDI learn, and realtime param automation combine to make some live work practical. In those cases the job of the UI would be make setup easy, let the musician bind parameters to their (likely) physical interface, and get out of the way. It's going to be a ton of work, but this is something that I've wanted to finish for quite some time. Judging by the response so far there's at least a few users who find this very valuable. I'll end up with another survey once a demo of the application is complete, so hopefully the combined feedback will result in a polished UI. As per other big name synths I've been trying to sort out that information, though mapping one teams decisions onto a different piece of software is pretty tricky. Each option out there provides a slightly different solution all of them slightly incompatible with their own trade-offs. At the end of the day the best way to make sense of the options is to watch almost any youtube video of someone using zyn to spot the "why in the world did they need to do ABC to accomplish X". Yep, thanks again for the feedback :) --Mark

On Thu, 28 Apr 2016 19:45:19 -1000, david wrote: Dock widgets as provided by Qtractor or Gimp are a better solution, apart from that an ultraconservative colour themes and structure distinguish the good GUIs from flashy crap. If for what reason ever, a flashy design should be preferred over sane ultraconservative layouts, then the design should be modern and not a copy of the most worse already outdated fashion ideas. Usability and decoration are two different domains. I expect decoration for a sofa and usability for a tool. One question of the poll is, if a user is willing to pay for it. Users are willing to pay a lot for new editions of old analog synth, users are willing to pay less for very powerful virtual synth. I recommend to take a look at the iStore. I doubt that even many Linux users are still using ZynAddSubFX, I suspect most users replaced it with Yoshimi. ZynAddSubFX and Yoshimi are still very good and usable synth, but IMHO users willing to pay for a virtual synth, nowadays expect something completely different. The sounds that are possible when using ZynAddSubFX and Yoshimi are very good, the provided presets are way too stale. I guess less people are willing to pay for a new ZynAddSubFX GUI, but more likely people are willing to pay for fresh presets. 2 Cents, Ralf

On Fri, 29 Apr 2016 11:35:09 -0400, Mark D. McCurry wrote: It shows how to use a minimum of space with maximised usability and good colour themes. And it shows what is much important, sound presets. The ugly concept of the restricted iOS devices, shows that people are willing to pay for sound presets, much more than for the synth. Instead of programming sounds on their own, they like to use in app purchase to get new sounds. Nowadays nobody is interested in another Oooh or Aaah choir, even not as a base to create new sounds. Good and new usable sounds are rare. I made this statement, because this is what most musicians pay for. For sound design people prefer easy to use synth, e.g. an Oberheim SEM (Oberheim provides a remake), however, most musicians want usable sounds, so I bet that most on this mailing list who own old synths, such as Oberheim synths, own a Matrix-1000. I suspect less musicians would be willing to exchange it with an Oberheim Matrix 12 and I bet, less people on this list own such a Matrix 12 or similar. There is a reason why some synth are wide spread and others aren't. Some synth are very good for sound design, but most synth are basically used with presets that allow easy to make minor changes, such as changing attack and release times, cut off and resonance settings, vector synthesis. All this most of the times is done by modulation wheels, after touch, a joystick or pedals. In the 80s it turned out that synth such as the DX7 were only programmed by some freaks, even if people had external hard or software to make it easier to program. We have similar situations for modern synthesis. People play granular synth, but they prefer to program Juno-106 alike, SEM alike synth. Taking a look at a real Juno-106 or SEM or even at the emulations you get for portable Apple devices, gives a good hint of what I call ultraconservative good design of a tool. Taking a look at a DX7 editor shows at what point it simply makes no sense to care more about GUI design, than to care about providing good presets. Regards, Ralf

On Thu, 28 Apr 2016, david wrote: In my opinion... knobs and sliders should operate the same. The mouse moves in a straight line either sideways or vertical. For the same size screen area, a knob can probably _show_ a finer resolution that a slider, maybe 3 to 1 -ish? In other words, the widget's most important goal is to show the control's position. The mouse movement to change that control can be independant of that. One of the early sequencers I used (on an Atrari) just had the numeric value as a widget. Holding the mouse button down and moving it up or down adjusted the value. (sideways may have worked too, but it has been a while :) This did (on such a low resolution screen) allow a very tight control packing. My favourite knobs are operated with either/or right to left, down to up. There is also no reason a horizontal slider needs to be locked to only horizontal mouse movement or a vertical slider to only vertical movment. (don't knock it till you've used it for a month) -- Len Ovens www.ovenwerks.net

On 29.04.2016 16:34, Len Ovens wrote: +1 on that. The advantage of differently sized and arranged icons is the recognizability of the state it is set to. With icons of faders it will use a lot more screen real estate when trying to convey a topological structure though. I guess the question between icons resembling either pots or faders doesn't fully cut to the essence. While I might prefer knobs for an envelope to use in a live context, I concur that the faders in the additive synth totally make sense and would be ridiculous with knobs. hth, tee

At least it's addressing my biggest complaint about Zyn: that silly, antiquated, almost-unusable fixed size window and fonts. But I'm just a casual user, not one who attempts even modifying a preset. I just pick presets I like. -- David W. Jones gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com

On 29.04.2016 08:53, Tim E. Real wrote: Since it's gathering dust otherwise, I may just throw this exploration on sliders and knobs in: http://i.imgur.com/7TmBmp9.png There's color coding for in-negative range, exact-zero, in-positive-range and maximum (the negative extreme is missing!). -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On 30.04.2016 02:34, Tim E. Real wrote: You're welcome! After struggling with label legibility vs making it stand out where the value bar ends, I figured the bar only needs very little height to remain readable, if the contrast is strong. The behind-the-label part only has to show where you can drag on, with the toned down bar making sure everything appears as a unit. The first variant with separate numerical entry area may suffer in the case where after dragging the bar to within the entry part, you might release and try a drag back to the left. Implementing a duration and/or drag threshold could avoid accidental numerical entry activation, but could only hurt on the rest of the widget. It might be better to not have the bar-range extend to within the entry area. This variant here happened because of stubbornness in wanting both maximum length for fine-grained value indication and numerical entry with fewest clicks! BTW, the thingies to the left of the sliders are meant as automation activators/indicators. The very first one is in the no-automation state. Clicking it should show/create an automation track. Once there is automation, it appears as in the second row. Drop me a line, if you would like to have the SVG file. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On Sat, 30 Apr 2016, Thorsten Wilms wrote: +1 My normal comment for this is that the movement of mouse need not track the indicator bar in the slider. It is ok for the mouse to move two (or more) units for each indictator pixel movement. This is common on remote control applications using tablets where there is not much space to begin with. However, for the application in mind, the ability to click on any spot of the slider and have the value jump to that point would make starting work on a new patch faster than dragging the value. (in a mixer fader one generally always wants to move from the old value without jumping) The design of knobs and faders for use in audio is not easy. -- Len Ovens www.ovenwerks.net

On 30.04.2016 17:38, Chris Cannam wrote: http://i.imgur.com/wLoZ2vG.png In the on-dark case, having background bars with the same color as the bottom bars, just with reduced opacity was good enough. But here, even with a very light grey, things get muddy fast, so I had to increase lightness. The colors of the numbers and bottom bars should appear to match. The Numbers are actually darker. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On 29.04.2016 05:24, Mark D. McCurry wrote: If I would be tasked with designing a better GUI, my first steps would be developing an idea of the architecture and expressing it in a diagram, to have an overview of all the building blocks and how they connect. This may also highlight somewhat artificial restrictions. The names themselves should be scrutinized. Then I would look in how far the diagram can inform on-screen layout. Even in the worst case, it would still be a great asset for documentation. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

Just want to add something to what I already wrote. Do not try to accommodate all use cases! There is no software package (apart from several of the "free software" ones) that do this or should do this. Trying to make software that works for everybody might result in software that works for noone. So, I would, for example, totally exclude the use case of live performance. A complex soft synth is not a live tool. Also, I would suggest sticking with one decision and not adding huge amount of options "for all those other use cases". This is the problem of many free software projects. If you decide to go for single window, stick with single. If you go for multi window, stick with it as well. And again, apart from asking opinions of this, I must say, very small community, reach out to people who use other synths, talk to people at KVR, for example. Make sure that if you go multi-window, for instance, this is a well thought out decision and not a "free software tradition" (not saying that multi-window is not an option, although I personally know of no well established synth that has multiple windows). By the way, a case that you might also consider - are you thinking of Zyn only in terms of standalone software or also a plugin inside a DAW? If it is inside a DAW - is it a good idea to have multiple windows? How will the synth look in side a DAW? Louigi. On Fri, Apr 29, 2016 at 10:16 AM, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote: -- Louigi Verona http://www.louigiverona.com/

On Fri, Apr 29, 2016 at 11:24 AM, Mark D. McCurry <mark.d.mccurry(a)gmail.com> wrote: "For even better user interface integration, custom Audio Unit Views should refrain from using overlay windows and from opening sheets or auxiliary windows other than for file browsing. All user interface elements should be presented inside the root Audio Unit View by laying out its content dynamically and resizing as necessary. The host window listens to size change notifications and will adapt automatically."

On 29 April 2016 at 17:18, Will Godfrey <willgodfrey(a)musically.me.uk> wrote: Ah, you're making me nostalgic! ;-) Every desktop has been playing catchup ever since. Every decent UI toolkit these days should provide the ability to undock / drag out window elements. I actually disagree with the idea of multiple windows by default, I just want to be able to drag out / undock the elements that make sense *to me at a particular time* to be in a separate window. That isn't a Zyn-specific point - using multiple monitors it's particularly annoying to be forced to use a single window. 2c Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org Digital Prisoners - interactive spaces and projections - www.digitalprisoners.co.uk

On Fri, Apr 29, 2016 at 12:18 PM, Will Godfrey <willgodfrey(a)musically.me.uk> wrote: This is Apple telling *DEVELOPERS* what to do or not to do if the *DEVELOPERS* want their plugins to interact smoothly with an Apple program. If the *DEVELOPERS* don't follow Apple's descriptions, then things may still work, but the user experience may be worse than it otherwise would be. You are free to (a) not use this particular Apple program (b) not use Apple products at all. However, I cited the stuff from Apple because a lot of people forget just how batshit crazy plugin hosting really is, and that for it work well, the plugin (developer) needs to be aware of certain basic guidelines. This is as true for the GUI side of the plugin as it is for the DSP side. I wasn't suggesting that Zyn or anything else needs to pay any attention to the details of Apple's guidelines, but I was noting that there are guidelines and I was implicitly noting that Ardour (at least) tends to work the same way. Which means : if a plugin developer thinks that they can just pop up new windows whenever they feel like it, and everything will just work right: no, they cannot. Hence, this is an argument, in the plugin context at least, for a single window design. The Acorn Archimedes did not feature multithreaded, multi-window realtime audio applications using gobs of memory and hundreds or thousands of their own on-screen controls loading arbitrary bundles of code written by parties unknown, and then running bits of that code both inside the DSP and GUI aspects of the program. The idea that the plugin developer can just do whatever they feel like and expect stuff to just work (in every host) is, to say the least, misguided. Your DAW/host is the *application* and it can do whatever it wants with windows (single/multi/whatever). Plugins are *not* applications and they need to follow some guidelines if things are going to work well (if at all).

On 29/04/16 18:45, Paul Davis wrote: [...] There's also an interesting user-experience corer to it. For example one thing I noticed in Ardour is when you open a LADSPA plugin window Ardour still 'grabs' keyboard shortcuts (e.g. SPACE to play, HOME to rewind); open an LV2 window and I'm most often hitting HOME to rewind just to discover I've set the parameter under focus (usually a shiny knob) to its minimum value :) This is just to point out consistency, I'm not sure what is better in general, in theory adhering to some Library (GTK?, QT?, ...) 'standard' would provide a consistent experience, but then I guess I'm the only one entering numeric parameters into plugins (and therefore usually prefer LADSPA..?). Lorenzo.

On 01/05/16 14:06, Paul Davis wrote: Well RTFM to myself.. I guess :) Lorenzo.

On 01/05/16 14:09, Paul Davis wrote: Yes that's the use case I was referring to, and just after scolding myself with a RTFM, I actually saw that the keyboard icon is there only on LADSPA plugins (at least on my system). An example of the use case LV2-wise would be one of the Calf ones... There's really no way for the "external GUI" approach Up to now I must say that probably the only real use case for having a (graphical) gui for plugins is maybe compression / limiting etc. where you can see graphically when and how the effect is actually 'kicking in..', although this could probably generalized. Otherwise just parameters for me lets me really concentrate on the (sometimes subtle) *audio* differences in tweaking parameters... But again I'm probably a bit of a corner case user.. :) Anyway, thanks Paul as usual for providing detailed insight. Lorenzo

On Sun, 1 May 2016, Lorenzo Sutton wrote: While I generally agree (physical boards have run with only knobs for a long time), The on the spot auto generated control layout for some effects makes things difficult to use. The one thing a GUI adds is to place the controls in a logical order. Any complex eq in generic controls makes the user stop their thoughts to figure out which control it is that they want to tweak. Takes the mind totally away from what they are doing. All of the switches grouped, all of the same filter grouped... so high and low pass, high shelf and then low shelf, then the parametrics in the middle. Open the GUI and things are ordered from input to output for overall gain and then from low to high frequency. A graph reminds you how it was set in the first place and also helps you to choose the right control to tweak (should I bring band 3 down or band 2 up... Oh right I am already using band 2 better bring band 3 down). Oh, and speaking of physical boards, a lot of them have GUIs for the channel strip built in EQ, noisegates, compressors, etc. Rack mounting ears and logos don't add much, but a nice layout sure does. It may be true that a plugin author could order the controls so that the generic gui orders them a little nicer... but I think it would still split it into columns in the most confusing place (in the middle of a group controls for one band in an eq for example). A well done GUI makes one work faster, make fewer mistakes, and allows the ears to be used more fully as the hand does not require as much attention. -- Len Ovens www.ovenwerks.net

On Fri, 29 Apr 2016 10:37:35 -0700 (PDT) Len Ovens <len(a)ovenwerks.net> wrote: Yes, I missed that. I had in mind the overall context of the thread. Apologies for the noise! -- 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 Fri, 29 Apr 2016 10:37:35 -0700 (PDT), Len Ovens wrote: 99% of musicians are interested in getting usable presets for synth that provide such a complex synthesis mixture as Zyn and Yoshimi provide. I consider myself as one of the few sound designers, anyway, with Yoshimi I most of the times use presets, instead of editing much parameters, I tend to make the sounds less bloated, by simply unchecking a synth. The best way to "edit" bloated sounds, when they are wanted, is to mix them by grains or in the case of Zyn and Yoshimi alike synths, by e.g. mixing volumes in a vector style as provided by Yamaha SY/TGs. We are living in an age were sounds are not only made by the synth. A lot of sound design happens outside of the synth. In the old days e.g. a LFO manipulated a filter of the synth unsynced to the played notes. Nowadays, we often prefer to record a synth and then to use filter with the automation feature of the DAW, for the track of the synth. The reason for this are less randomized results, without the unwanted side effects caused by an unsynced LFO. Speaking for virtual synth we should keep in mind, that when used in combination with a DAW, the DAW usually is part of a quasi modular synth. IOW e.g. instead of a synth's unsynced LFO and filter, a DAWs filter and automation are used as a replacement. So even the sound designer crowed not necessarily likes to program too complex virtual synth, with overloaded GUIs, instead presets are used and manipulated by filters, vocoders etc. provided by plugins of the DAW.

On Sun, May 1, 2016 at 7:57 AM, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote: Sorry, but this is still missing the critical difference between the question of how *applications* behave and the one of how *plugins* behave. I was not mentioning this in connection with application behaviour at all (where I remain a fan of (optional) multiwindow designs. But plugins are different. Thus, any discussion of Zyn's GUI that includes reference to a possible implementation as a plugin needs to consider this.

I would say that Zyn is actually an exception from the rule - loads of presets and many of them are good. On Sun, May 1, 2016 at 5:34 PM, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote: -- Louigi Verona http://www.louigiverona.com/

Am 01.05.2016 um 00:47 schrieb Mark D. McCurry: Also known as a modulation matrix. There are two big schools of modulation routing design in synths, with the first further divided into two approaches, which mirror each other: A1) Aach modulation source (LFO, envelopes, MIDI CCs, hardware controllers, velocity, etc.) has a selector or intensity param to assign it to one or (a fixed set of) multiple modulation destination(s). A2) Aach modulation destination (filter, pitch, waveform, amp level, etc.) has a selector or intensity param for each modulation source, which can can affect it. b) There is a modulation matrix, usually with a fixed number of slots, and in each slot you can assign one modulation source to one modulation destination and specify the intensity (and sometimes an offset too). Mixing modulation sources in scenario B is usually implemented via special modulation sources (e.g. Modwheel + LFO) or by providing special functions, which take two modulation sources as input and then act as a modulation source in another modulation matrix slot. If a synth doesn't have many modulation sources or destinations, approach A is usually easier and quicker to use, but often some useful modulation routings are left out the design due to space constraints. A modulation matrix is very flexible, but doesn't lend itself very well to "knobby" interfaces and though setting up mod matrix routings via MIDI is possible, MIDI controllers do not generally have good support for it (they would need to support dynamic labels for controls, which can't be done with MIDI CCs alone). Chris

On Sat, 30 Apr 2016 21:13:48 -0400, jonetsu(a)teksavvy.com wrote: ZynAddSubFX and Yoshimi aren't emulations of analog synth. Even not all very good, much wanted, real vintage analog synth produce deep warm sounds, e.g. the Prophet 5 comes to mind, it doesn't provide Oberheim warmth. It's wanted to have different sound colours. For ZynAddSubFX and Yoshimi the analog section is ok the way it is. The concept of ZynAddSubFX and Yoshimi is comparable to that of e.g. the TG33. The TG33's digital section is cheap compared to a DX7, but since it provides to mix sounds, as ZynAddSubFX and Yoshimi do too, it doesn't matter. What is missing for most, if not all virtual free as in beer synth are sound sets that musicians really want. E.g. most of the free available sound fonts reach just the level of the MT-32's default presets, IOW lowest level, nearly unusable. However, it's possible to get good sound fonts. As soon as a virtual synth isn't for free as in beer, it must provide a set of really usable sounds for all kinds of music. It's not a solution to download a zillion Zyn sounds and to spend month with separating the wheat from the chaff. Musicians want jazz kits, rock kits, dance kits etc. and no GUI ever will make ZynAddSubFX and Yoshimi the first choice of synths for sound designers. ZynAddSubFX and Yoshimi are preset usage kind of synths, were a vector control and just a few crucial settings are much wanted, such as attack time. Zyn isn't missing a "deep sound algorithm", it's missing presets. Presets are also useful as basis for sound designers and a must have for musicians who just want to make music. Regards, Ralf

On Sun, May 01, 2016 at 09:28:23AM +0200, Ralf Mardorf wrote: I think this is a fair point about a lot of Open Source tools. For all the claims that you hear "real musicians don't use presets, they make their own patches" I think the truth is that if you can't reach for a tool and immediately get something good and inspiring from it you're unlikely to persist with it long. A well organised, wide range of musically useable presets transforms a synth, or effect's appeal. Without that it's a matter of faith that the synth will actually repay your time investment in it.

People of my age as children build childish discrete circuits or NE555 based circuits, when we became older and started making music, we needed usable sounds. However, some people get more usable sounds from a NE555 and a few resistors, than most people on YouTube get when performing with an EMS VCS 3. https://m.youtube.com/watch?v=Cp3Og2uR_a8 https://m.youtube.com/watch?v=_4AF_eRZvGY It takes some time to learn how to make sounds and how to make music. A lot of people just want to make music and get usable sounds. Regards, Ralf

On Sun, 1 May 2016 08:15:46 -0400 Paul Davis <paul(a)linuxaudiosystems.com> wrote: This is one thing u-he is currently doing. Acoustic drum modeling presentation at the Superbooth 16 in Berlin: https://www.youtube.com/watch?v=Oyuag1uaZR4 No trigger of samples.

Ralf Mardorf wrote: As far as this is true, it is not an issue of ZynAddSubFX specifically, but Linux audio in general. We have an abundance of great software, but no portable standard for sharing presets among DAWs and other plugin hosts. I would guess that there is enough diversity and experience in our community to develop, share, review presets. Informally, we already do that when someone writes to the list asking about appropriate parameter settings. What exactly would a preset include? In Nama, presets are called "effect chains", and consist of a series of one or more LADSPA/LV2/Ecasound plugins with their parameter settings. A limited subset, including LADSPA and LV2, could be portable among Linux audio plugin hosts. This implies a single signal path (e.g. track). Perhaps some processing could involve a more complex topology, signals being split, processed and rejoined. I'd be willing to take a stab at drafting a spec using JSON (which Nama already uses), however before that I'm wondering if a sequence of plugins with their parameters would be sufficiently expressive to describe what commercial presets provide. -- Joel Roth

Paul Davis wrote: Do you mean the defaults that are displayed by analyseplugin? If so, I wouldn't call that a preset, in that it is a single set of default parameters provided exclusively by the author. You may be correct in theory, but the top search hits suggest that practice is otherwise: In this third hit on Google, titled "LADSPA Vocal Effect Presets" the author is distributing his parameter settings as screen shots. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&a… Another hit is Guitarix documention, describing differences of Guitarix and LADSPA plugins. https://sourceforge.net/p/guitarix/wiki/How_to_use_the_new_ladspa_plugins/ Simple LADSPA plugins can just be added to a track, maybe some parameters adjusted, and you are done. In contrast, the Guitarix plugins need a preset file which is generated and modified by Guitarix, and the meaning of the 5 assignable LADSPA parameters depend on the settings in the preset. The audacity docs also rank high. This is important because Audacity is so widely used. http://manual.audacityteam.org/man/effect_menu.html LADSPA effects support real-time preview. They do not support import/export of presets but do support saving presets for use in Audacity only. Another part of the Audacity manual says: Many VST effects support import and export of named factory presets in a single FXB file, but LADSPA and LV2 effects do not support import and export of presets at all. So if there is a standard for exchanging plugin parameter sets, I haven't seen it, and it is invisible to Google (invisible == not appearing on the first page.) Almost everyone who uses a DAW for audio production has their own sets of preferred plugins and parameter settings. Where are these being shared? Can we do better? -- Joel Roth

Paul Davis wrote: I looked into this format, and see it is XML, found some presets in ~/.ladspa/rdf/ardour-presets.n3 To make it easy to share presets it might be valuable to have an app-independent way of browsing and comparing them. We share a lot of music, here, and I hope that presets could be shared as readily. It surprises me, really, since without proprietary pre-cooked offerings, everyone producing music with Linux invests a lot of time to find suitable plugin settings. You'd think that open source source community would share them as well. -- Joel Roth

On Sun, 1 May 2016 02:44:01 -1000, Joel Roth wrote: I already mentioned, that it's an issue for all free as in beer synthesizers, that aren't emulations of hardware synth or are unable to import sound fonts. We need to make sounds on our owns or to import zillions of free as in beer sounds, to search and pick out the few usable sounds. It is in so far an issue for Zyn, as IMHO opinion an improved GUI might not be a reason to pay for a new release of Zyn, while IMHO providing a release that comes with a huge selection of amazing good sounds, is a very good reason to pay for it. However, the coder was in a pissy mood by my statement and mentioned that by his research, a GUI is more wanted, than a selection of sounds. Mixing an Oooh or Aaah choir with a virtual generated analog pad sound is something nobody needs anymore, resp. if needed, those sounds already exist. Proprietary synth that mix synthesises similar to Zyn provide enhanced sounds. Not the user interfaces, with all their vector, wobble and arpeggiator/step sequencer features are that important. The gimmickry wears away. The unobtrusive, but impressing preset sounds are important. A piano gets never out of fashion, neither do some synths sounds ever get out of fashion. Providing new sounds, that are always good for musical expression are what IMHO people are willing to pay for. Regards, Ralf

On Sun, 1 May 2016 16:36:58 +0200, Christopher Arndt wrote: They are very usable, just overloaded. By turning off e.g. one kind of synthesis and adjusting a filter or attack time, they become well usable, but not unique. To adjust the existing sounds, there's no need for a new GUI. Zyn and Yoshimi already provide what is provided by a lot of synth from the 90th. A lot of wanted and useful sounds, but nothing I would pay for in 2016. At least making a recording of MIDI CC data, as part of the sound, triggered when playing a note, as the TG33 does, would be helpful. IIRC this should be provided for Yoshimi soon or later.

On Tue, 3 May 2016 13:38:18 +1200, worik wrote: It works with Firefox 46.0, but the address bar shows https://docs.google.com/forms/d/1AVHqmUxjgoLJQQr5Dt_prDbfUz6yi-GC-J5SVgj6Mw… perhaps this link works for you too.