Is Open Source a diversion from what users really want?

I don’t think anyone is arguing that what you’re asking for doesn’t have great possibilities, like the two you mention here. It’s just that at this point in the game, it would take a monumental re-working of the source code. And honestly, if it gets in the way of the goals that Paul and Robin have already announced, I rather live without it. And I think most Ardour users would agree. Better clock and expanded MIDI functionality are easily more important than recoding the GUI to allow Lua scripts a UI. I’ve heard time and time again people asking for better MIDI tools. In fact, my friend who I converted to Ardour a couple years ago just switched to Studio One because he got big into MIDI and said it was more powerful. Your suggestion is great, its just a matter of cost-analysis. This software is pretty much maintained by 2 individuals, who somehow make the time to chat with us :slight_smile:, and there are more important priorities that involve way less overhaul of the source.

3 Likes

The best time to plant a tree is 20 years ago the second best time is now. Looking at the posts I would say most are in favor to add some Lua GUI elements. I think if is was assumed and taken for granted that "most Ardour users would live without it…I don’t feel like there’s a lot of us looking for this…) we would not have this thread.
The idea would bring NEW users to Ardour, if you compare the amount of of Reaper users to Ardour users. Remember Winamp ? it was made for users to be able to customize things how they like and not be a slave to how the developer thought you should use it, well, the same guy made Reaper, and it “is pretty much maintained by 2 individuals”. There is just so much potential there rather than plodding along with how it is, a lot of time and trouble has been put into all those Lua bindings and look how many users there are now because of a Windows release. This will open the door for other script developers like in the Reaper forum, rather than waiting for something to be implemented it would take the load of the Ardour developers and it can be made that same day with a script that you can make yourself or ask someone.
It matters not to me if it’s implemented or not, I’m just giving you a fresh eye perspective from what I experienced coming from Reaper to have a look at Ardour’s scripting to see if I can port ReaTrak over from Reaper to give Ardour users the same features, I’m not charging anything for it, and it would be a hard thing for me to do, so it would be an easy way out for me if Ardour is kept how you suggest.
I spent the last 11 years hard labor in the pg music Biab forum and beta development getting them out of the Delphi 90’s and help develop the vst plugin version, I just don’t have that energy anymore to worry too much about Ardour :frowning: when I first went to the Biab forum there was so much defensiveness from the long time users from the Disk Operating System days and any suggestion of improvements or change was given a hard time, you saw new users come and suggest improvements and constructive criticism but they were soon got rid of as you can tell by the reply’s to their post and their number of posts. So that’s why it stayed in a time warp for so long. And those users that were got rid of for suggesting such features, well those features are now implemented and are actually being used by the users that knock their ideas and suggestion years back, true story !
But then I fell off the floor when I went to the RapidComposer beta development where just about every suggested feature was implemented virtually overnight, that was a real shock as you would wait up to 10 years for things to be implemented in the Biab forum.

This is what you have already with Lua script, what else does it need ? just a button and a couple of other things maybe.

2 Likes

Again, you are simplifying my argument. My argument isn’t that plenty wouldn’t want this feature. If we turned this into a binary poll: “Should a UI for Lua scripts be priority over the proposed goals or not?”, I promise you most of us would want better MIDI functionality as soon as possible. I would wager that most Ardour users do not use any Lua scripting.

1 Like

So what is the better MIDI functionality you are looking for ?
I know they are working on implementing Chordimist.

So what is the better MIDI functionality you are looking for ?

I think you should start a new thread if you want to open that can of worms. We’ll quickly derail this one :slight_smile:

5 Likes

Put enough developers on the case, and it’s no longer an either-or question, which brings us back to the original problem of getting more developers involved.

People contribute to open source projects that … they are capable of contributing to and that they feel passionate about. There are some (look at the commits on the kernel from intel addresses) who actually get paid by their employers for such, but that is generally because their employers use that aspect of free software.

But since ardour is unlikely to attract the attention of IBM as a critical business need at which they will throw programmers, that means people who are passionate about it.

To get people who are passionate, we have to expand the user base. Expanding the user base means concentrating on features that are most important in making the difference as to why someone would choose a different DAW over Ardour.

So those make-or-break features need to be prioritized. What those are, I have no idea. The thing is, using ANY daw proficiently is a major investment in learning curve, just as a user. So it might not be an easy sell.

However, here are some really powerful benefits Ardour already has that I think are big selling points.

Licensing. Not just that its open source, but if you have used any of the big names like ableton or any of the more pricey plugins, you are limited to node-locked or iLok licenses that absolutely suck to manage or transfer around anytime you upgrade your motherboard or switch to a larger disk drive or whatnot. And heaven forbid you should actually own two computers on which you want to use the software. You can make it work, but it is a major investment in time and fiddling. Ardour will work on whatever computer you install it on. Projects are self-contained in a folder, and you can transfer them wherever you want. The licensing schemes are major overhead. (Except for Reaper, of course.)

Signal routing. The signal routing matrix of Ardour is fantastic. IMO it is the easiest and most clear matrix available. Although other daws will let you do the same thing, Ardour does best at presenting “what goes where” and letting you control it, split the signal, and send stuff wherever you want.

This is really huge when you want to make something that sounds coherent. The best way to use reverb isn’t necessarily by putting it on a recorded track and dialing in the amount of wet you want. Instead, take your instrument tracks that belong in a certain space (say, foreground or background) and route them to two busses – the destination bus, plus the reverb bus for that space. Then route from that reverb bus to its destination. Adjust the reverb there, and it is all coherent. You CAN certainly do this in other Daws but with Ardour this is easiest.

All daws have automation, and I’m sure other daws can do something similar, but I have to say Ardour’s ability to record desired automation (or just “touch” it in that one critical spot), and then play it back is killer.

I think its existing strengths are very sellable.

3 Likes

The signal routing on Ardour really really is incredible. I can’t get over how clumsy it is in every other DAW I’ve used (except Mixbus).

3 Likes

I have seen blender mentioned a few times in the comments. While there are some similarities between the two, there is also one very big difference. Blender is not a real time platform. It does not matter if the work in progress stutters or stops, it is the render that matters. Blender is not made to take live video in, but rather video files. Ardour on the other hand, does record audio in real time with real time monitoring of previously recorded tracks or may even be used as a live mixing setup in some cases. This does limit what can be scripted and what scripting languages can be used in a way that Blender does not have to deal with.

However, a lot of the scripting people are asking for is also not real time but rather batched commands to save entering a sequence of commands with a mouse or keyboard (or control surface). The GUI and other control surfaces are already, from what I can see, not real time so much as real time-ish. The control portion suggests what needs to be done and that is taken care of the next time real time code is dealing with what is being controlled. For most scripts exposing only non-real time options would be enough and in fact using a script that has the ability to also do real time dsp may make it easier to make mistakes in this area.

In my case, while the thought of learning c++ was a hurdle, I have found it does have advantages as well. c++ will generally not allow me to build something with mistakes in it. I am probably not the average user though.

3 Likes

MIDI I/O needs to be realtime safe, so at least control-surfaces that use MIDI have additional constraints.

Realtime-safety is about reliably meeting the process-deadline. A given method must have a known, upper limit on execution time to be realtime-safe.

1 Like

In some cases software freedom is vital for safety; it might be of life-or-death importance to know that your operating system doesn’t spy on you, or that the software in a medical device or a voting machine can be independently audited.

By comparison, the safety of Pro Audio software is unimportant – at worst you can airgap your music PC to make sure nothing is spying on you.

So if we alter the title of your post a bit …

Is Open Source a diversion from what music software users really want?

I would 100% agree. :slight_smile:

I’ve wondered about using the term “Software with superpowers” to describe apps like Ardour which, for example, has all the features of a regular DAW but is also open source and thus has the superpower of being 100% customizable. It’s interesting to realize that REAPER might fall in that category too despite being closed source. I wonder if people often run up against limits in REAPER’s scripting, or if they hit bugs which are hard to resolve without viewing the source code?

1 Like

I wonder if people often run up against limits in REAPER’s scripting, or if they hit bugs which are hard to resolve without viewing the source code?

Yes, we do.

It is a bit. It assumes that everybody is comfortable

  • builing a compiler environment
  • messing with the source code of the application
  • learning a high level language like C or C++

and also has the time and energy and interest to read and understand the existing source code in order to modify it. And most people really aren’t. It raises the bar really really high. And that is something that developers seem to not be equipped to understand. Because for you it’s easy, right? It isn’t for everybody. And scripting has a lot less steep a learning curve. Which is why people go on about it. It really isn’t about doing a build. At least for me it isn’t.

It reminds me of Linux. Linux became a lot more widely accepted when it actually started working out of the box. And I remember the look of complete incomprehension on some people’s faces when we aregued that Linux needed to be more userfriendly. These are the same people who find VIM more userfriendly than Word.

So I do think that there is huge mnerit in how the FOS community does things. As long as you don’t assume that this is for everybody. In order to have wider user appeal you need a low resistance option as well.

1 Like

Maybe replacing the waf buildsystem with cmake would also clear a hurdle, as it would enable developers to work with any IDE they are accustomed to.

They can already do this just fine. Arodur is not tried to any IDE.

Personally I started to use CLion a while ago, and after using it for some time I prefer it to Eclipse or vim. Unfortunately CLion only supports cmake natively, but they are working on Makefile support.

On the longer run … a view from the distance.

Greetings to everybody here. As I’m new in this venue, some words to introduce myself: I’m a musician (12 years of classical piano education, since 1 year I also study guitar), a business admin guy with experience in technology and business strategy and (many years ago) I also worked a while programming in C. I appreciate Ardour and your work very much indeed.

Let me share some thoughts on what most musicians (and computer users in general) wishes were in the realm of audio software.

Before I begin with the actual topic, some words on the Open Source question:

Open Source Software is vital and essential for the people, even when they do not use it. FOSS always limits the options of software vendors to do what comes in their mind to maximize profit through the pure existence of FOSS’ existence. They then always know that people had an alternative and are not forced to suck up whatever they present them. That alone was enough reason to stay with an open source license and policy.

It’s a good thing having capabilities for DIY, to have maker spaces and hacker spaces, to have some tools to not being dependent. It’s always good to be able to help oneself.

Also, it’s no surprise that many FOSS users don’t ever have a look into the source code. There’s always a percentage amongst people beeing oder getting more involved than others - no matter whether it’s about fire fighters, paramedics / first aiders or any realm else. One can just work with the involved ones (and create wonderful things with them) and see one’s own work for the rest as a gift to them.

Now on audio software (and hardware). I also view the surroundings of DAWs and plugins as this helps to remind us what all this is about and what the higher goals are.

When I recently began to search for a complete new setup for music recording and production I also tried a panorama sight on the whole landscape of hardware and software, presented to us. Which let some general questions come up, i.e. “how would a setup look like when we were in paradise ?”

I’ll do a bit of a tour d’horizon and then come back to implications for the Ardour project.

We would love to see important open standards and norms (regarding interfaces, protocols, whatever) to be respected by the industry as this gives us more freedom to combine our tools matching our individual needs. Compatibility, flexibility, freedom. Instead, many companies try to establish their company norms, in fact hindering and even blocking a positive development.

The Inet would never have grown so fast if there were not accepted and supported standards such as TCP/IP, BGP, HTTP/HTML, SMTP and many more. The appearance of MIDI was of great relieve and help.

But VST vs. AU vs. LV2 vs XY is a negative thing. The many company norms in the field of Ethernet-based audio transmission are a mess for the user: Dante, SuperMAC, AES-variations, and whatnot … Companies do this to imprison their users and to bind them to the company. Bad. It is even difficult to find audio interfaces providing USB 2.0 class compliance. It’s a long ago that one company proudly announced to have invented the backslash and therefor needs much payment for their products. But since then, the same story happened again and again and again. Remember the browser wars, all those dialects and derivates of the C language and of SQL. And so many cases more. Those inventions, made from whatever company, are annoying like flies.

The struggle when trying to exchange stems from one DAW to another and even among FOSS DAWs also is not so nice. Not to talk about the enduring competition between the mess of the various Linux Sound System(s) and the Open Sound System used on BSDs.

The Rosegarden port crashes on FreeBSD because Rosegarden relies solely on ALSA - so there’s no way to get a Notation-MIDI-sequencer synchronized with Ardour on FreeBSD. That’s pretty bad as a songwriter-producer just also needs notation-MIDI-synchronization.

The Non DAW project cant be ported because it’s code relies otherwise on specific Linuxisms. Again and again also much sound trouble with browsers and other apps alone within the unioid community while there’s no advantage from stubborn rules for anybody. Ardour by the way is without any issue using OSS and virtual_oss (for more channels) with JACK on FreeBSD.

We’d love to see that the times of much headache (regarding compatibility issues) are gone. We’d love to just buy or otherwise deploy a product, plug it in and see it works seamless and fine.

We’d love to see better hardware at lower prices - instead propriarty standard hardware at high prices. Respected norms and standard instead would ease mass production of standardized hardware following the “economies of scale”, indicating that doubling production output leads to potential cost savings of up to 30% per unit.

What happens when a product is produced in 32.000 units instead of only 1.000 units ? The price can go down from i.e. 500 USD to only 84 USD - without using parts of lower quality and without otherwise compromising quality. But this needs mass production only possible with the acceptance of standards.

It is not efficient to use a big PC or Mac with lots of memory for a DAW and dozens of plugins as well as for web browsing, messaging, text processing and accounting. It hinders the systems real time capabilities also by too many processes, it wastes energy, it costs a lot of money. Also, so far, the whole computer often has to be replaced when grading up to the next level of capacity - instead of only parts of it. Resulting again in loss of money.

Instead the core processes of a DAW and plugins could run on a 1U / 19" pizza box server using COTS PC parts instead of DSPs while the GUI could also run on a relatively cheap PC or Tablet with real time capabilities not needed on that client. Following the client-server-architecture, one could switch from a desktop PC to a notebook to a tablet as GUI client - and vice versa. Just as needed and convenient. I.e. a tablet, fixed on a tripod, was fine when recording an acoustic piano or as a singer or …

The pizza box, using Linux, instead could be patched for increased real time abilities. Plugins could be sandboxed for even more improvement of stability and reliability. Such a setup would quickly also accepted in professional studios and on stage. That is what UAD and others actually do, just not with standardized hardware and instead with their own standards, with low production amounts and at high unit prices while nothing real special is inside.

When more computing power was needed - i.e. for better physical modelling - one only could replace the pizza box. Or - in case some sort of cluster computing was available - buy a second pizza box to increase computing power.

But even without true cluster computing it probably was possible to distribute plugins to two pizza boxes. Assumed a standardized Ethernet communication for audio was established. I already talked about the need for such open standards, ideally of course in form of a RFC.

On the client side, additional applications were also relatively easy to realize. Shouldn’t it be possible, to build a client/GUI functioning as a multitrack looper while using the pizza box server with it’s core functionality as a recorded/DAW ? Such a looper could be controlled from a tablet GUI as well as from simple MIDI foot switches. Same story in case a tool for live usage is needed, be it for a DJ or for a band needing some prerecorded snippets. Or just a plugin host and a software providing a set list with according configuration. Always the same core functionality on the pizza box would be used.

And what about integration of communication networks for Audio/Video-calls, such as the Jitsi project (video conferencing), to use for online jam sessions, online recording and collaboration of musicians otherwise ? Of course, there’s the latency coming from overall internet communication. But that will not exclude every online collaboration (of course also depending on the distances and resulting latency). Again, the same pizza box with its core functions would be used.

Most of us would probably love to see that there were a bit less of the many Linux distros and otherwise new FOSS proijects and forks. Of course, creativity needs its space and innovation is driven by people trying things. The downside otherwise is a split up of development teams, slowing down all projects.

Bundling forces, at least developing common libraries in turn would ease and speed up each projects progresses. Where feasible and where indicated. I’d guess there were many options for common libraries.

I recently stumbled upon the JUCE framework/SDK. Liked very much, was I read about it (did not try so far). But what I don’t like is their license policy. Shouldn’t their be a thing like JUCE completely published under the GPL 2 ? That would speed up so many development projects while the same time, there’d be lots of contributions to that framework itself - as everybody in the sceene needs it.

I believe, members of many FOSS communities much too often fight each other instead to remember the bigger picture. One might understand that hint that way, that more collaboration between FOSS communities would serve everybody. I’m not talking about the Ardour project here. I saw such struggles in many other projects.

So, what’s in it for the Ardour project ?

I try to summarize what I read here in this thread:
The scripting topic is related to the client side of Ardour. There’s a wish - at least of some users - for more scriptability, flexibility and adaptability of the GUI. Paul Davis also mentioned being not too happy with the earlier decision for GTK+.

The Ardour projects has not too much core developers. It seems the only other collaboration partner and major DAW project is Harrison mixbus. Please correct me if I got something wrong.

I believe, much could be reached without even writing a single code line - just through collaboration amongst FOSS und unioid communities. There need to be standards across the projects. Sound system on Linux/BSDs, Ethernet-based audio communication and so on. Also a common strategy for the overall development of categories of projects.

This mainly seems to be a matter of conversation and conferencing. In case of success it would help all communities and all of their software.

The same with libraries. Sharing libraries - as difficult it initially may be - would relief developers and make capacity free for progress otherwise. While probably the quality of underlying libs would improve and thus improve the apps quality.

Spliting up software projects in a server part and a client part in a sense was also some sort of modularization. On both parts could be worked independently from each other as long as the interface was fixed. There then could also be alternative and exchangable clients with different strengths (and weaknesses) and different functionality. Everybody could chose. More people could be made happy. If there was a client providing enhanced scripting - even better.

And by the way - not that I found weak points in Ardours current GUI but my impression from what I read so far about Ardour (also Paul Davis interviews and announcements, i.e. on the nutempo project) that Ardours core seems to be brilliant and may be better than many or even most other DAWs. Thus, may be the Ardour core (server) could be offered to other DAW projects while in return get something from them. That of course leads to the question of interfacing between cores/servers and clients. Another matter of talking.

Common libs could also cover developments of client/GUI software in the way JUCE does it. This would improve the GUIs of many projects (remember the critics and following activities regarding MuseScore). Same time, new developments would be much easier. Using a GUI library of course is not the same as scripting. Nonetheless, it was a easier way, to write code for a software - at least easier but diving deep in core functions - thus, it was a step.

Again, talking was needed to find commonly supported standards for protocols and interfaces. Wouldn’t it be nice if the Open Source community overall could talk with one voice in direction of software vendors ? Couldn’t commercial software projects convinced to also support such a standard if the saved money through it ? And if they may be even enhanced the number of potential customers through it ? Maybe the Open Source community as a whole needs something like ambassadors for such talkings. Forming foundations and alliances to support the same goals might also be helpful. That sometimes might do more for the communities goals but additional code lines. In some cases.

And maybe open source people should think more like business people from tine to time. Business people also think in terms of mergers and acquisitions. Are these people mad ? Or do they have reasons for what they are doing ?

Staying in business language, I much more often see things like “outsourcing” and “splittings” (forks) in the open source world but mergers. That results in smaller and smaller “business” units, each of them less powerful.

I know very well, that much of what I wrote about is said easier that it was done. There are also many young guys in the FOSS scene trying to prove something - and a bit stubborn from time to time. Not easy to talk with them. Nontheless, I believe what is needed should be done somehow.

Beg your pardon in case I got something wrong. And by the way, you all are heroes.

Kind regards
Tom

If you’re going to write such a long post that gets into specific internal aspects, it would perhaps be wise to be more familiar with those internal aspects.

Most notably:

  1. you can already run Ardour in the mode you’re describing, via two totally different techniques (a) use X Window (b) using headless ardour combined with some control protocol.
  2. We already make massive use of libraries. The dependency stack for Ardour is nearly 2GB after compilation.
  3. People who write DAWs don’t want “engines”. Traktion have offered up their “engine” and although I could be wrong, my guess is that it will see more or less zero use as an engine to another DAW-like application. There are way, way, way too many workflow and design decisions that ripple all the way back into the core - the idea that someone could write the perfect DAW engine which could be shared by DAWs with widely different design and workflow models is, sadly, a fantasy.
  4. I don’t believe I’ve ever said I was unhappy with GTK+. Other people, mostly people who have never contributed anything to the project, are unhappy with GTK+. Those of us on the inside know that GTK+, like any other toolkit including Qt and JUCE, has its advantages and disadvantages. We also know that for an application like Ardour, most of them don’t actually offer as much as they might appear to do.
  5. The niche of audio software in general is very small. The number 2 company in the mid/late 2000’s was Steinberg, who were bought by Yamaha for about $15M which is basically pocket money for a lot of “tech-sector” related stuff. Narrow that down to Linux and/or FLOSS, and it becomes a tiny niche in a tiny niche. What this means is that there’s no cavalary that is going to rush in and save or fix anything. Nobody gets rich doing this stuff (though some people make a nice living from it). It’s not of interest to Linux vendors, it’s not of interest to most software vendors. The one company recently that tried to go “big” (ROLI) are now in quite serious trouble financially and have already sold JUCE.
2 Likes

Hi Paul,

did not claim to know much about the sources or internals and already said two times I was not sure with some things. I just wrote about what many users would love to see in future (not next year).

I know of course about the X option but that doesn’t really helps regarding the scene I described.

I’ve read earlier some vage hints about the headless deployment option and was intrigued but couldn’t find much about it. Ardour seems to be the only project providing such an option (what I see as a big plus for Ardour). That exactly however was the initiation of my thoughts on a full client-server-architecture.

If however the control protocol was already sufficient (what I don’t know), then it actually should already be possible to allow for the development of alternative clients of any color / functionality - even if the headless deployment of Ardour was not already the perfect solution. It was a step and as such an advantage.

I couldn’t call all DAW projects and ask them, if they wanted a DAW engine. I’m not in the network of DAW projects and I’m not authorized to ask that question. Of course I can imagine that the GUIs and engines are mostly deeply interwoven. Impossible to know about the feasibility of a splitup if one hasn’t gone through the sources of all those projects. So I just put it on the table, to understand as a question.

Well, if a splitup was too time consuming and/or projects are not interested, nothing could be done there of course. But that doesn’t mean, it wasn’t of advantage, could it be done. I could only throw some thoughts into the discussion. I did not expect, every idea to be welcome.

I did well notice what you wrote earlier about the dependency stack of Ardour. But I did just not talk about Ardours stack. I talked about options to save manpower and time on FOSS projects in general. You will certainly know very well that in many projects there’s much much work done again and again (for sometimes questionable reasons) und much of this work could be saved and put into better subprojects if priorities were adapted. If they are ready to do so is just their decision.

On GTK+ you wrote “Was it a mistake to use GTK+ for the GUI of Ardour? Almost certainly yes, all things considered…”.
I understood that as “not really happy”. Sorry if I understood you wrong.

Also, I did not do a careful comparison or even code review of GTK, Qt and JUCE. I did not even recommend JUCE. Instead I wrote I’d dislike their license. There seems to be a growing trend to use JUCE. They argue that it provides also support for Android and iOS as well as “audio functionality”. True or not true. But my actual thought was, that FOSS communities might - on the long run - build their own libs/sdks for the same purpose. May be like JUCE or with it’s functionality. Or different from it, if indicated. That however would certainly pay off on the long run. Every head of a solid FOSS project knows many people in other projects and also has influence, he might use for the good.

I did not talk about making money nor did I talk about any cavalry. Also, I’m certainly not here to make money. I’m here because I like Ardour.

I did talk about the mindset of aggressive money makers on the other side of the table, i.e. Yamaha and others… With FOSS projects and small development teams of prop software on the opposite side of the table.

I did talk about the money makers thinking and about the need also for FOSS projects to understand their thinking in terms of business strategy even if their own goal is not money but just good and free software, many users and independence. Sun Tzu says “know your enemy” and as all this is about claiming the users machines, so there is competition between the ones with pure money goals and the other ones with better goals.

You asked for opinions regarding the need for and way to more flexibility and adaptability (scriptability) of the Ardour GUI. Most people answered with their personal priorities in mind. I put my finger on an option for another form of GUI adaptability for the long run, provided the case that a good SDK / framework makes that much easier than with todays need for low level C++ programming.

And I underlined the importance of standardization, even that was not asked but also touches possible development paths on the long run. Having open standards is vital for audio software/hardware as for other IT products and if there are non, one should create them and try to establish them.

Apart from web and some other standards, I don’t see much activity in the FOSS community to form standards (with JACK and LV2 being great exceptions in the audio realm). I don’t see much strategic thinking there also. So I mentioned this as even the best programs can’t succeed if they are forced on the back foot or kept down by smart standardization tactics from competitors.

That’s all I said. It’s up to you to through everything over board or recognize one thought or another as not so weird.

Regards
Tom

Did dig into the JUCE acquisition thing. It seems, the financial troubles came from the fact that ROLI was pumped up with venture capital while sales of ROLI controllers did not meet the goals. Meaning, not the JUCE project caused the case. It seems, ROLI just sells off assets to get cash in, with JUCE being one of those assets.

But however, the new owner is PACE (owner of iLok and other IP stuff). Not that good news. I really see the need for a modern GPL framework/SDK.

Another project claims to have built a realtime audio optimized OS based on Linux. Elk Audio from Stockholm. Same thing there with the license policy. I also wouldn’t be surprised if they claim tons of patents, may be blocking natural developments in future.

I therefore repeat: The FOSS communities overall and in general should really defend their claims and think and act more strategic. Please come together, make a good plan, form alliances and foundations, fix standards, act together for more success when it’s about to spread good open source software.

The results always were overwhelming when the communities did that - and were less than that when they didn’t do it.

Tom

I really see the need for a modern GPL framework/SDK.

JUCE is GNU GPL licensed.