Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 12/10/2017 09:37 PM, Paul Davis wrote: > On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber < > markus.see...@spectralbird.de> wrote: > >> You can still statically link for example with FLTK >> > You still need to ensure that the host can integrate with FLTK (or any > other toolkit's) event loop. Without some explicit awareness, events etc. > will never be delivered to the non-host toolkit. > > > >> and derivatives or roll your >> own. On Windows I think Steinberg even provides a GUI toolkit for VST >> plugins if >> > Not in any effective form. Their old version (more than a decade old) was > based on *Motif* for X Window. There's a newer attempt at this, but it no > notable benefits unless you wrote the host using the same thing, which is > essentially impossible because of it's limited scope. > > > >> I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits? >> >> Maybe robin can give better recommendations since he seems to have done >> some work >> on lv2 GUIs. (maybe see https://github.com/x42/robtk ) >> > robtk is probably one of the most obvious answers, but even robin can > identify some drawbacks. > > the thing is that on other platforms, there's a single event loop that all > possible toolkits connect to. on Linux (X Window (and probably Wayland > too)), this isn't true. Qt has done work to use the same glib-based event > loop as GTK but this isn't a general solution. On Windows or MacOS, it > makes no difference what toolkit the host and plugin use, because > everything is inevitably going to get routed through the same event loop > (and redraw cycle). On Linux this is not true, and it's the root of most of > these issues with plugins. > > Hm, I did not think about that hard enough, honestly. Then again this makes me want to explore the idea of a plugin GUIs separately from the DAW process. This is not a new idea, but has it already been implemented and explored in detail, apart from the obvious translation of MIDI/OSC from/to track automation? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 12/10/2017 08:43 PM, Gordonjcp wrote: > On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote: >> On 12/10/2017 03:31 PM, Paul Davis wrote: >>> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber < >>> markus.see...@spectralbird.de> wrote: >>> >>>> >>>> Just employ static linking when sensible. >>> unortunately, several large toolkits of various types make this impossible >>> because they themselves use dynamic (runtime-driven) loading of shared >>> objects. GTK (and its dependency stack) is a particular offender there, but >>> I believe the same is true of Qt. You can't statically link against this >>> type of toolkit if your goal is to end up with a self-contained binary. the >>> g* stack has made a few improvements in this area in recent years, but >>> AFAIK it still isn't possible to build a self-contained binary. JUCE >>> differs from this, I believe. >>> >> That is exactly the problem with plugins. At the same time I'd say: >> "Don't use these GUI librarys for plugins and do not load any plugin that >> exports these symbols." >> and be done with it, let offensive software die. In my eyes writing a plugin >> GUI >> in GTK/Qt is very bad practice for exactly these reasons. > So what would you write it in instead? > You can still statically link for example with FLTK and derivatives or roll your own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits? Maybe robin can give better recommendations since he seems to have done some work on lv2 GUIs. (maybe see https://github.com/x42/robtk ) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 12/10/2017 03:31 PM, Paul Davis wrote: > On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber < > markus.see...@spectralbird.de> wrote: > >> >> Just employ static linking when sensible. > > unortunately, several large toolkits of various types make this impossible > because they themselves use dynamic (runtime-driven) loading of shared > objects. GTK (and its dependency stack) is a particular offender there, but > I believe the same is true of Qt. You can't statically link against this > type of toolkit if your goal is to end up with a self-contained binary. the > g* stack has made a few improvements in this area in recent years, but > AFAIK it still isn't possible to build a self-contained binary. JUCE > differs from this, I believe. > That is exactly the problem with plugins. At the same time I'd say: "Don't use these GUI librarys for plugins and do not load any plugin that exports these symbols." and be done with it, let offensive software die. In my eyes writing a plugin GUI in GTK/Qt is very bad practice for exactly these reasons. Or even better: Do not run the plugin GUI inside the DAW procces. Surely this comes with it's own challenges as plugin developers now have to develop IPC mechanisms inside their plugins and a way to negotiate how the GUI process connects to the plugin DSP part etc... . Or go the JACK way, but for a DAW we already know that this has it's own problems. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 12/10/2017 12:14 PM, Filipe Coelho wrote: > On 10.12.2017 11:51, Markus Seeber wrote: >> On 12/09/2017 02:32 PM, nils wrote: >>> Bottom line: It turned out the Windows way of shipping all or most >>> libs with the program is a really good way to compatibility. >> Just employ static linking when sensible. >> >> ... >> >> The current way of bundling shared libraries with the application ist just a >> dirty workaround >> for Problems that combines the worst parts of static and dynamic linking, >> introduces bloat and solves problems that are mostly caused by employing >> dynamic >> linking in the first place. > > This is not related to Linux, but since someone already mentioned Windows.. I > have bad news for you. > See > https://forum.juce.com/t/important-breaking-change-juce-will-now-use-dynamic-linking-for-the-windows-runtime-by-default/25276 > > Basically, with the latest updates, you can only load a maximum of 64 > statically built plugins in a Windows DAW. > But this only concerns the windows runtime library, right? Everything else can still be linked statically. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 12/09/2017 02:32 PM, nils wrote: > Yes, that is possible and I wholeheartly lobby for that because library > bugs and mismatches are common and could be avoided. > > Ardour does it and I do it in my own programs as well, or at least will > if properly released. If you can copy a library into your source tree > (Python in my case) why would depend to the external ecosystem? > > Some Linux distributions (mostly very small and unknown though) do it > already but the "way of forefathers", the shared library, is still stuck > in peoples head. No the "way of forefathers" was static linking. > > Bottom line: It turned out the Windows way of shipping all or most > libs with the program is a really good way to compatibility. Just employ static linking when sensible. There are less ways a linker can screw that up during runtime and your application size will be even smaller since we have link time optimization these days, startup time will be faster and run time may be faster. Sure, if LGPL licensed libraries are used, this may be impossible but from a technical standpoind dynamic linking for self containing application bundles does not make sense unless you actually need to link dynamically (e.g. license requirements, plugins etc.). The current way of bundling shared libraries with the application ist just a dirty workaround for Problems that combines the worst parts of static and dynamic linking, introduces bloat and solves problems that are mostly caused by employing dynamic linking in the first place. Yes I understand why people do it, yes it works and yes it solves social and resource problems so that people can move on. But the real technical problem is not solved. > > On 12/09/2017 02:24 PM, Louigi Verona wrote: >> This is a good point, Fons. >> >> On Windows it is typical to bundle a program with stable libraries and >> dependencies. Is this strategy thinkable on FLOSS systems? >> >> >> >> >> >> >> ___ >> Linux-audio-dev mailing list >> Linux-audio-dev@lists.linuxaudio.org >> https://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
On 09/23/2016 05:13 PM, Paul Davis wrote: > The last time I was working with such a person was deeply illustrative: a > small technology company doing audio on raspberry pi and beagle boards. > Using JACK. Having an insanely hard time even getting it work. Even with me > sitting in with them. Their experience is common. Maybe even the norm. We > never targetted JACK for such uses (focusing on desktop scenarios). > Developers think it is cool, was developed on the same OS as they are > running their new embedded platforms - awesome! Except ... not so much. > Exactly what I have experienced. It is all well for prototypes and for testing out stuff, but when things become serious, it all falls apart and people may notice, that jack is not even a good fit for their usecase which may be better fit by a small custom application. Also people have a hard time understanding even the "basic" concepts, for various reasons. I have seen someone trying to build a simple processing chain for streaming audio and setting up a proprietary application as a JACK client. That was interesting to watch. It took quite some time for him to learn how to even build, install and use JACK in a meaningful way, even with me providing some help. In the end it worked out for testing and evaluation purposes but I'd never seriously consider that ready for production usage. This may sound harsh, but this stuff is simply not a nice choice for mainstream production use and so are many things in the LAU universe. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Multiple JACK servers connected in one host?
On 03/12/2016 01:30 AM, Robin Gareus wrote: > > If you want to dig deeper, compile jack2 with --profile it can print > nice diagrams like > http://www.grame.fr/ressources/publications/Timing.pdf including > wake-up times for each of the clients; then again this is fairly > advanced and the issue in your case is likely simpler. > Obtaining timig information the clients would have been the next step to identify then critical path. I think something can be learned from this data. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Multiple JACK servers connected in one host?
On 03/07/2016 08:37 PM, Jonathan E. Brickman wrote: [...] > > What is happening right now, is I have seven synth+filter chains, all > run through the single JACK server, all feeding eventually into the one > sound card. I have more than ample CPU to run them all, but as you and > others have explained, one JACK server is reaching its limits to handle > them all because of the limits of the synchronous nature of everything. > So what I intend to do, is to run all of the chains independently, > asynchronously, on their own JACK servers, and then combine them all > into a separate final which will connect to the sound card. This is > being done already with as many motherboards as desired, but I would > like to do it within one very powerful box. > Since you did not give much case specific information about the topology of your processing chain, it is hard to tell where the problem is in your case and how to solve it. Not sure what's up about all this asynchronous talk, maybe we talk past each other? (pun intended) Maybe some visualisation of your jack graph could help, I think patchage can export the structure of that into a dot/graphviz file, you could attach that. Information about the strain each of these filters puts on the CPU would be helpful as a hint too. That would not be the number at the top of htop, but next to the process of each of these filters. Except from that, Paul and Fons already made the point about how this is supposed to work. Best regards Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Multiple JACK servers connected in one host?
On 03/07/2016 02:12 AM, Jonathan E. Brickman wrote: > Greetings, everyone. Since I am using 85% of JACK DSP in my primary > production box, while using 14% of the CPU and 1/8 of the RAM according > to htop, it appears that I need to develop a way to move forward :-) 14% of what? One physical core? One virtual core? All cores? Chicken? > I would like to use the power of my box to do the same internally. Jack should be doing this already in a single instance. > > I have taken a number of hours over the last few days in testing. Thus > far, my impression is that netjack1, netjack2, and jacktrip are > explicitly not set up for this. Using jack2, netjack1 and jacktrip > worked fine for one client/slave, but a second one froze both, and > netjack2 did not work at all, I found a web reference stating that > multijack explicitly does not do localhost unless explicitly set to do > so at the TCP/IP stack programming level. Using jack1, netjack1 did not > connect at all, so I decided to halt for now and ask Those Who Know :-) > > So far, the only clearly workable option, has been to try the Docker > lightweight virtualizer, and run each JACK server and related > application chain in its own container. Anyone have better ideas? Yes, maybe take a step back and try to find the problem before finding a solution. >From what I just read: * You noticed, that there is a high DSP load for JACK * You noticed, that there is a low CPU load on you box, which has most likely multiple physical cores? So I assume you think the following: Ok, my Hardware still has free CPU resources, and since JACK is supposed to be a smart thing, it should be able to utilize all of my CPU cores. One could think, that JACK just needs to put your clients on different CPUs so they can run in _parallel_, using up more CPU Cycles and increasing. Sadly it is not that easy, since this assumes, that your processing chain actually _can_ be parallelized. Can it? Depends... If your processing chain looks like a daisy chain, you are out of luck: mic -> client1 -> client2 -> client3 -> speaker (fig 1) Since each client must wait for the previous one, only one client can do its work at a time, which means only one of your cores can be utilized _at a time_, the others will just sit there idling around. On the other hand, if your processing chain looks like this: mic --> client1 ---> speaker \-> client2 -^ ^ ^ \-> client3 --/ / \-> client4 ---/ (fig2) the clients 1,2,3,4 can run at the same time. JACK _can_ schedule them to run on 4 different CPUs, which means you can reach a higher average CPU load while keeping the DPS load lower. There are many more details, but the most important thing is the question: "Can my processing chain be parallel?" "Can I do anything to my processing chain to make it (more) parallel?" I stop here trying to interpret what you were trying to achieve and maybe the best thing you could do to get some tips is to describe your processing chain, maybe something can be worked out. A picture in form of a graph, says more than a thousand words in this case. Best Regards Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RME madi latency
On 02/03/2016 03:40 PM, Jörn Nettingsmeier wrote: > On 02/03/2016 02:54 PM, Fokke de Jong wrote: >> Hi Adrian, >> >> I could’ve guessed you were on this list as well :-) >> I’m going to try this tomorrow when back in the studio, or maybe I can >> even do it remote if I have left everything patched up correctly :-) >> >> I will come back with the results. >> Thanks for your input! >> >> fokke > > watching this with interest, keep us posted about your results and > longer-term experience with this card! > > > best, > > > jörn > I have tested the card for a short period of time and can confirm that it works as intended. The only thing is, that the mixer controls are not available via alsamixer and the internal routing matrix is fixed. On the other hand, I guess that is a bonus as something you can not set, can't be set wrong ;) The buffersize can confuse applications which assume, that the buffersize is variable and is always (buffersize = framesize * periods) but I guess that this is not an assumption that should be made in the first place. Measurement with jack_delay seemed plausible too back then. Was the driver already included in mainline? I saw the patch on alsa-devel but kind of lost track of it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio (rambling)
On 04/19/2015 01:35 PM, Gordonjcp wrote: On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote: Hi All, As promised just at the closing ceremony of LAC, an email opening the discussion of User Experience on Linux Audio. To all Developers, please use this as a checklist and consider supporting each item. It will improve the user experience. 1: Splash Screen If an app takes more than one quarter of a second to open, use a splash screen to give feedback. Feel free to contact me directly to collaborate on a splash screen graphic if necessary. Ensure the splash is shown immediately, before lengthy operations such as scanning for Just as long as it's not modal, or better yet make it optional. There's nothing worse than a big ugly graphic blotting out the middle of your screen preventing you from doing anything while you wait for some buggy slow piece of crap to load. Splash screens are a symptom, not a solution. I think both have a point here. Users, especially Windows users are often quite strange creatures. They come from an environment where Software is notoriously slow, bloated and faulty, so for example they come with a few subconscious expectations and assumptions: 1. I do not trust this thing in front of me, sometimes it works, most of the time it doesn't. I hate it, I don't want to use it and it is a PITA. 2. If I command my computer to do something, it must be complex and complicated, otherwise why would I have the computer do it anyway? If it was easy, I could do it myself! 3. Because computers do complex and difficult stuff, this stuff takes time and makes noise, (Freezing the gui for a few satisfying moments, loud rumbling of the hard drive, and and and, Sometimes displaying an ominous loading- or progress-bar). This kind of feedback is the resemblance of hard work, exactly the hard work I expect the computer to do for me (see 2.). While it does the hard work, I anxiously sit in front of it full of awe and expectations whether the hard work will show any usable result or just abort with a cryptic message some stupid programmer most certainly put in just for the purpose of annoying me. 4. If I click on a button and I can't notice any hard work, something must certainly be wrong because no work was done. So this save button must obviously be broken, so better press it again and again... oh wait, it is greyed out and deactivated, better call the developer and tell him, that the save button does not work... Nr 4 did actually happen to a fellow developer in the past, so what did he do? After all his effort to uncouple the UI from the background processing and optimizing the speed and responsiveness of the application, he silently shed some tears and put in progress bar that runs for a fixed time of maybe 1.5 Seconds.Now the user can be sure, that the program has actually received his command and acted (or at least acted as if it acted) according to the users command. Because seriously, saving must at least take one second because it is hard work, otherwise it is obviously broken ;) Someone nasty could say, that users want slow and buggy software, but I am not that cynical, I guess some feedback is enough to give the user a good feeling. There are other alternatives than classic splash screens. 1. locking the UI in a visible way 2. displaying a loading bar 3. Be creative, maybe play some hard-drive crackling sound via speakers? Splash screens have the advantage of empowering the developer to put marketing relevant stuff there, Donation Buttons, logos, version numbers... so it's probably not entirely about UX I guess. Just my 2€ -- Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Android's 10 Millisecond Problem
On 04/16/2015 07:10 PM, Ralf Mardorf wrote: [...] Is it possible to run an Android device by a power supply, when the battery is empty? Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev There is no such thing as the one representative android device since android runs on many different devices, made by different manufacturers. Comparing Android to Apple is a bit of a problem here. Basically, it depends on the device and the workload. For example I can do a lot of stuff with a Galaxy S3 Phone and the power reserves of the (stock) power supply are adequate for usual tasks, even for installing updates, and demanding tasks. For a tablet, this may be entirely different, since the screen is much bigger. Cheers, -Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [p...@linuxaudiosystems.com: [Jack-Devel] jackaudio.org website shut down due to hacking]
On 06/27/2014 11:54 AM, Michał Koziarski wrote: Hi, I could take this on in case there's still need for a volunteer. I'm a professional web developer. I'm also in favour of gh-pages, that I use quite a bit, as long as it's fine for it to be a static site. It's simple, fast, free, made for open source project sites and it's git so it works great when different people make changes to the site. Of course I can't really spend more than about an hour per day on it, what with my day job and all, but hopefully it's not a massive job and I think I should be able to get it done in a finite amount of time. Does this sound reasonable? If so, what would be the next steps? Michał Even tough the site is in fact on-line again, I feel the need for a little bit of restructuring. There are some pages, for example the front page and the download page, that could benefit from a better Design, so I'd like to hear your opinion about that from a web developers perspective. Greetings Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [p...@linuxaudiosystems.com: [Jack-Devel] jackaudio.org website shut down due to hacking]
On 05/30/2014 10:00 PM, Adrian Knoth wrote: Hi! I'm sure there must be users out there who are familiar with web stuff and are burning to help their favourite inter-application audio framework. ;) Step up, please. PS: There is also a semi-complete move to GH-pages. If your're familiar with github, you could be the ideal volunteer. ;) Cheers Hi, GitHub-pages means, some kind of static site generator may be used? Sounds good to me, even tough I'm not a web developer, getting some experience something doesn't sound that bad. I'd like to evaluate what i can do, would you make a list of contents and requirements for a new page? I got this from the other list: * the FAQ * applications list * API documentation * stuff that was on trac.jackaudio.org (which is a wiki) Is the Trac currently used as a Project-management tool and will it stay as such, or is it just used as a wiki? Maybe it's time to go through the Information on the site and throw out some old stuff during the process. TL;DR I'd like to take this on, but it will take some time, as i have to get into these things and certainly won't be using Drupal ;) -Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AES67 + JACK
On 05/16/2014 05:37 PM, Jamie Jessup wrote: I would love to see this happen in the world of LA. I was recently about to embark in a HW project for an AES50 implementation, however after a quick skim of the standard this sounds a little more exciting :). A Dante Virtual Soundcard style thing for ALSA/JACK would be amazing. There is a proprietary ALSA driver for (at least) some Dante Cards, but you have to ask your reseller specifically for it and pay an additional fee. -M ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
