What do we have? What do we need?

[davephillips]

Isn't it what linux is all about, being able to take someone else's project and reviving it and making it better?

I wouldn't say that's what it's *all* about but I take your point.

Synths like Add64 and WhySynth are, imho, very nice instruments that would benefit from a bit of updating. If the authors of these are no longer willing/able to do the work, this is where I think we need some new energy put: into making some good apps already in existence even better.

FYI, Sean updated the sources for WhySynth recently.

And yes, I'd love to see the DSSI-based synths get ported to a more widely-utilized format (LV2 and/or VST).

Linux-based synths work much more solidly than VSTs (in my experience)...

Not sure what you mean by that. Do you mean "better than emulation a la Airwave etc" or ... ? Because I've been using the u-he VSTi synths a lot recently and they do seem to be "working solidly" here.

Best,

dp

[GMaq]

Isn't it what linux is all about, being able to take someone else's project and reviving it and making it better?

Synths like Add64 and WhySynth are, imho, very nice instruments that would benefit from a bit of updating. If the authors of these are no longer willing/able to do the work, this is where I think we need some new energy put: into making some good apps already in existence even better.

The idea of "throwing away the old because it's old" is very typical in the country I was born in (USA) but I don't epouse that idea any longer. If something is useful, I say, let's keep it, use it and build on it. Linux-based synths work much more solidly than VSTs (in my experience) and I would hate to see some very good-quality instruments get put to the wayside because they aren't "new."

brian

Hi Brian,

This isn't 'throwing away' in the sense you're talking about, and we the user are not throwing them away, their respective developers for various reasons stopped developing them and in the meantime better applications and implementation methods have come along... My point was IF someone revives an old standalone project, please fix the remaining issues it had and then port it to a plugin, so I think we agree more than disagree

For instance if I recall Phasex generates an unwanted distortion and has some other serious issues, if someone comes along and makes it an LV2 or an LXVST with it's old problems still there then that is not a useful upgrade... I will admit that becoming introduced to U-he and other commercial Linux vendors has somewhat reduced my patience for doing professional production with half-baked plugins. We have some great Open-Source plugins that certainly can go toe to toe with anything commercial, on the other hand sourceforge and Github are also loaded with Google SOC and other such projects that are very much 'builder-beware'.

I think what is great about Linux is that the source code is there for you or anyone else to build and enjoy it on your own system whether it is new, old, complete or incomplete... Reviving and distributing broken software to the masses is a bit different story I think...

Further to that I think the subtext to Rob's original post here is "What do we still require for a complete professional production environment?" I definitely believe Linux Audio has raised the bar enough to compete with anything else out there but we definitely need to shed, re-purpose or update a significant number of applications and obsolete standards (ie DSSI) and tidy up our house a bit as one of the actions to strive for this ideal of a professional production platform.

[ssj71]

so maybe what we need is everyone to go use some plugins/apps that they see the potential to be awesome in, try the latest versions then make bug reports/feature requests on what it will take to get that polish in there? I'd certainly appreciate such feedback on my projects.

Many such requests might get rejected, perhaps its beyond the scope of the author's interest or vision, but if there is enough visible interest in the community, it's much more likely to happen. For example I've considered porting whysynth to LV2 (just haven't had a moment to look into it) but didn't know if anybody would use it. I did the rkrlv2 ports because I thought lots of people would use them, but have had little feedback so I haven't focused much on them. Maybe somebody else has considered reviving a project like this and would be willing to do so. Maybe Sean himself is willing, but just needs some help. IDK, we just need to talk it out really. I'll do whysynth.lv2 myself, but 2050 will likely come before I get to it TBH.

[Quirq]

My biggest hurdle in the Linux world is the ability to visually draw MIDI note velocities in Ardour and Mixbus, especially for drum programming.. I know, I know it's all cleverly done with mouse scrolling but that's not visual. I am completely satisfied with Ardour and Mixbus and have produced a few complete albums with them and their Audio capabilities. But the lack of ability to draw note velocities keeps sending me back to Hydrogen which I really like but is becoming increasingly kludgy to use especially with multiple drum tracks. Ardour's MIDI editing has other great features and capabilities but every other sequencer I've done MIDI programming with over MANY years (Digital Orchestrator, CubaseVST, Reaper, EnergyXT) have had the very simple feature of drawing MIDI note velocity visually even with timeline-based editing, Call me crazy but I absolutely loved MIDI editing in EnergyXT

I'm with you on that. As someone who shuns "humanisation"/randomisation and goes to great lengths to program variability into my drums (to the extent of having no two bars the same, even if the only differences are the velocities), H2's method for velocity is very quick and easy to use. For this reason I tend to program in H2 and export to midi to import into Ardour.

Another bugbear I have about Hydrogen is the fact that the lead/lag (another really great feature that allows for very quick and easy to implement humanisation) isn't saved in exported midi files. It's nice being able to have everything tied to beats but a bit before or a bit after, it makes it easy to duplicate bars and vary things with whether it's in front or behind the beat, in a similar way to how easy it is to duplicate and vary velocities. If Ardour had lead/lag and velocity like H2, I'd ditch Hydrogen in an instant (I use LS or Carla to load the actual SFZ files so it's only midi programming I currently use it for).


Back to the main topic, I'd dearly love to see a usable spectrum analyser that looked and behaved like Voxengo's SPAN:



I use it for mix/mastering analysis; I was giving feedback to a friend for a CD release in December and looked again for comparable native analysers but went back to SPAN, even though it was a bit of a pain launching it separately and connecting everything up. (Now I've got Carla-rack that would be much, much less of an issue. But still it would be great to have something native.)

I've looked at all the native analysers and none of them seem to come close. It's nice/clear to look at (important when you're using it for hours on end), the slope can be varied (useful for that gradual gentle slope down from low to high frequencies when things are balanced), but above all else, it's the fact that the display is smoothed and not at all spiky and is equally detailed across the spectrum (many analysers seem to be less detailed at the low end than they are for the highs). The image above looks like it's probably not on the more smoothed-out Mastering setting and is a bit spikier than the settings I use.

[glowrak guy]

i made a new version of the ladspa wrapper, with a tool to convert all installed ladspa plugins to vst, and a bunch of bugfixes.. i don't want to hijack or derail this thread, so this will probably be the last post here about it.. from now on, i will make updates available on my blog, and for updates and other announcements, i might make a new thread in the plugins section here instead..
http://torhelgeskei.blogspot.no/2017/01 ... -v001.html

The Invada 'early reflections' reverb is one of the ladspa jewels,
used with the wrapper last night, gorgeous sound! Probably an lv2 version exists also.
New specific topic in plugins area is a good idea.
Cheers

[briandc]

Isn't it what linux is all about, being able to take someone else's project and reviving it and making it better?

I wouldn't say that's what it's *all* about but I take your point.

Synths like Add64 and WhySynth are, imho, very nice instruments that would benefit from a bit of updating. If the authors of these are no longer willing/able to do the work, this is where I think we need some new energy put: into making some good apps already in existence even better.

FYI, Sean updated the sources for WhySynth recently.

And yes, I'd love to see the DSSI-based synths get ported to a more widely-utilized format (LV2 and/or VST).

Linux-based synths work much more solidly than VSTs (in my experience)...

Not sure what you mean by that. Do you mean "better than emulation a la Airwave etc" or ... ? Because I've been using the u-he VSTi synths a lot recently and they do seem to be "working solidly" here.

Best,

dp

Hi dp,

it's nice to see that WhySynth is still being maintained. So I stand corrected on this one!

When I mentioned VST synths, I mean exactly what you guessed. Emulations just aren't the same thing. (Although some emulations definitely work better than others in my experience.)


brian

[sadko4u]

I've looked at all the native analysers and none of them seem to come close. It's nice/clear to look at (important when you're using it for hours on end), the slope can be varied (useful for that gradual gentle slope down from low to high frequencies when things are balanced),
but above all else, it's the fact that the display is smoothed and not at all spiky and is equally detailed across the spectrum (many analysers seem to be less detailed at the low end than they are for the highs). The image above looks like it's probably not on the more smoothed-out Mastering setting and is a bit spikier than the settings I use.

I think it's just an illusion. In reality, most of all analyzers use FFT transform that means that all control frequencies are separated at the equal frequency interval. When using logarithmic frequency scale, of course, low frequencies will have 'larger' interval rather than high frequencies (some of them can also be thrown out because there are not too much pixels to display them. The solution is just to increase the size of FFT transform that will cause to lowering of interval between control frequencies.
What I actually see on the screenshot you gave, that low control frequencies are just interpolated with polynomial splines. But in fact it doesn't add tolerance to the graphical output. Also higher frequencies are (probably) decimated, and decimated intervals are also interpolated by polynomial splines, so you see only very averaged picture instead of full picture.
Maybe I'm not right and you can correct me.

[ssj71]

First I'll say bravo to Quirq for giving specific, objective reasons on why he likes a non-native plugin better than native ones.

What I actually see on the screenshot you gave, that low control frequencies are just interpolated with polynomial splines. But in fact it doesn't add tolerance to the graphical output. Also higher frequencies are (probably) decimated, and decimated intervals are also interpolated by polynomial splines, so you see only very averaged picture instead of full picture.
Maybe I'm not right and you can correct me.

I think you are exactly right sadko, but Quirq is also right. Even though it's less accurate data, a mode like this can help the user to mentally process the data on screen better, even if it's less accurate. If you are using it for balance of frequencies, rather than trying to surgically remove or boost this or that freq, then I think a "frequency smoothed" mode is a good idea. Really it makes sense to have some independent control over smoothing WRT time AND/OR frequency. Especially with a few good presets ("Mastering," "high-accuracy," etc.) then it would be an even more useable and capable analyzer.


As for ardour's midi programming, I really think we need the hydrogen editor ported to LV2. Drop that in your midi track, sequence away. You can bounce it to an ardour track too if you want. I've wanted that since A3 was released.

[chaocrator]

why so many posts about „it would be nice to make things like in windows/mac world“??
yesterday, i played with windows again. there are some really cool instruments available there, but in general, windoze ecosystem still is a horrible crap.

[glowrak guy]

... The life expectancy of the great classic
composers was decades shorter than our's is, so they had far less time,
worse health, and their main distraction was survival itself, rather than
paying bills in a world of distracting screens to stare at.

Just to clarify:

Monteverdi 1567-1643 66 yrs.
Palestrina 1525-1594 69 yrs.
Josquin de Pres 1450-1521 71 yrs.
Vivaldi 1678-1741 63 yrs.
JS Bach 1685-1750 65 yrs.
Haydn 1732-1809 77 yrs
Mozart 1756-1791 35 yrs.
Beethoven 1770-1827 57 yrs
Schubert 1797-1828 31 yrs.
Mendelssohn 1809-1847 38 yrs.
Wagner 1813-1883 70 yrs.
Liszt 1811-1886 75 yrs.

So it wasn't the Classical period that did 'em in, it's the early Romantic era's fault.

I've already lived twice as long as Schubert. You'd think I'd have more to show for the time I've been around.

Best,

dp

It's not easy for teachers to quantify 'what you have to show for it', because so much of the 'have'
comes to fruition in the future of student lives, and then at times in locales where students
have moved on to. The 'have' does exist, but is not so easily stored or stolen.

I did a little searching on some in your list. I was surprised at the amount of controversy
immediately available. Open the can of worms, and it contains the tip of an iceberg!
I suppose we should be thankful the masters were not arguing analog Vs digital,
in (anti)social-media accounts. The composers lifespans and number/depth of works
didn't seem to follow a linear routine, an accurate spreadsheet of such data would probably
be fodder for a Doctorate Degree program.
Cheers

[Quirq]

First I'll say bravo to Quirq for giving specific, objective reasons on why he likes a non-native plugin better than native ones.

Thanks. I know it's an emotive topic and I'd rather have a native solution as I think there's less chance of things suddenly stopping working for no obvious reason when you upgrade I've only ever used Linux for music production, so where I use non-native plugins it's usually for specific reasons (which make sense to me, if not everyone else!) rather than just "because that's what I was used to under Windows". Not that I think arguments of familiarity or nice eye candy are totally without merit, both help with workflow

I think you are exactly right sadko, but Quirq is also right. Even though it's less accurate data, a mode like this can help the user to mentally process the data on screen better, even if it's less accurate. If you are using it for balance of frequencies, rather than trying to surgically remove or boost this or that freq, then I think a "frequency smoothed" mode is a good idea. Really it makes sense to have some independent control over smoothing WRT time AND/OR frequency. Especially with a few good presets ("Mastering," "high-accuracy," etc.) then it would be an even more useable and capable analyzer.

Thanks, you've very eloquently summarised what I was trying to say. The reason I got into using SPAN was because that's what the mastering engineer Ian Shepherd used in his Home Mastering EQ course (which I found incredibly useful). When I looked at all the native analysers to put things into practice, they all seem to be built more/just for precision, which is fine for most purposes but not as helpful for the broader-brush approach of mastering.

There are some analysers that are also scaled in a way that I don't find helpful – being marked 100, 200, 200, 400, 600, 800, 1kHz, 2k etc with appropriate ticks in between is far more useful than 110, 220, 440, 880 etc. I understand why that's done, but it's harder to work out quickly where a feature of interest occurs in the spectrum unless it's centred around one of the marks. I think as well, having the area under the line makes things easier to read; most analysers do that, but not all. For example:

As for ardour's midi programming, I really think we need the hydrogen editor ported to LV2. Drop that in your midi track, sequence away. You can bounce it to an ardour track too if you want. I've wanted that since A3 was released.

Now there's a good idea

[sadko4u]

There are some analysers that are also scaled in a way that I don't find helpful – being marked 100, 200, 200, 400, 600, 800, 1kHz, 2k etc with appropriate ticks in between is far more useful than 110, 220, 440, 880 etc. I understand why that's done, but it's harder to work out quickly where a feature of interest occurs in the spectrum unless it's centred around one of the marks. I think as well, having the area under the line makes things easier to read; most analysers do that, but not all. For example:

Please could you summarize the functions you need? Maybe I'll add them in the nearest future to LSP Spektrumanalysator.
What I've already noticed, you need:

• Fixed step between control frequencies (add decimation at high frequencies).
• Vertical lines of multiple of 440 Hz.
• Smoothed frequency curves.

Is there also something that I've forgotten?

[Quirq]

Please could you summarize the functions you need? Maybe I'll add them in the nearest future to LSP Spektrumanalysator.

What I've already noticed, you need:

• Fixed step between control frequencies (add decimation at high frequencies).

I must admit I don't really understand what this means, I'm afraid I don't know a thing about DSP

• Vertical lines of multiple of 440 Hz.

Sorry for the confusion, what I meant was that "musical" values aren't helpful. Having things in nice round base 10 numbers (as your analyser currently does) is what I need for my simple brain

• Smoothed frequency curves.

Is there also something that I've forgotten?

Yes, smoothed curves and probably a slower response time as well, so that it can be smoothed a bit in time as well as in the frequency domain.

I think as well it would be helpful to be able to control the slope, or at least have it fixed at 3.0 dB/octave, which seems to be fairly normal. In SPAN I use the Mastering preset, which gives a smoothed and more slowly reacting display as mentioned, but I also change the slope from the default setting of 4.5 dB/octave (which the manual says "makes it look considerably “elevated” towards the higher frequencies in comparison to most other spectrum analyzers available on the market") to 3.0 dB/octave.

Also, the option to have the area under the spectrum filled in (probably less dense than the colour for the curve itself) might be helpful, though this is probably not terribly important, I just think it makes things a little easier to read.

[sadko4u]

Sorry for the confusion, what I meant was that "musical" values aren't helpful. Having things in nice round base 10 numbers (as your analyser currently does) is what I need for my simple brain

Okay.

a slower response time as well, so that it can be smoothed a bit in time as well as in the frequency domain.

Did you try to rotate 'Reactivity' knob in LSP Spektrumanalysator?

I think as well it would be helpful to be able to control the slope, or at least have it fixed at 3.0 dB/octave, which seems to be fairly normal.

Did you try the 'Envelope' combo in LSP Spektrumanalysator? 3dB/oct (in terms of power) or 6dB/oct (in terms of amplitude) is actually the Pink noise envelope.

Also, the option to have the area under the spectrum filled in (probably less dense than the colour for the curve itself) might be helpful, though this is probably not terribly important, I just think it makes things a little easier to read.

It also makes things more CPU time to render. I can try to add it but do not guarantee that it will render quickly.

[CrocoDuck]

About what we have, I think we need more physically modelled synthesizers. For example, something like pianoteq would be ace. Actually we already have pianoteq. It is commercialized for Linux as standalone ALSA/JACK application and VST/LV2 plugins. Try the demo by the way, it is pretty damn good in my opinion. What I would like to see (or code if I will ever get proficient enough) in the future is more open source software to physically model musical instruments.