Re: [LAD] Jack port alias names
Tim E. Real termt...@rogers.com writes: So there's no way to tell if a Jack system port actually belongs to (our own) ALSA client? If a2jmidid is used in dbus mode, you can map ports through the dbus calls: method name=map_alsa_to_jack_port arg name=alsa_client_id type=u direction=in / arg name=alsa_port_id type=u direction=in / arg name=map_playback type=b direction=in / arg name=jack_port_name type=s direction=out / /method method name=map_jack_port_to_alsa arg name=jack_port_name type=s direction=in / arg name=alsa_client_id type=u direction=out / arg name=alsa_port_id type=u direction=out / arg name=alsa_client_name type=s direction=out / arg name=alsa_port_name type=s direction=out / /method lpatchage and ladish use this to display one box per alsa client and to merge mapped alsamidi ports and jack audio ports into same box given that jack client name and alsa client name matches. Of course this is a workaround for subopitmal jack API. Other workaround is the alias mechanism. Hopefully one day jack API itsell will get fixed, in 2020 maybe :] As side note, a2jmidid and its jack internal client incarnations should use multiple clients. And then the client autorenames hit the fan. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpqhazvmsGvp.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] dead audio projects worth resuming
Adam Sampson a...@offog.org writes: The two obvious big bits of work that could be done to it are to add JACK MIDI support (which should be fairly easy), and to add support for LV2 plugins (a bit trickier). For the latter, I was wondering if it might be easier to retrofit JACK Rack's nice interface to one of the existing LV2 plugin hosts... lv2rack is open for features that are present in jack-rack -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpWjRXC67vm1.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: On Mon, Jan 4, 2010 at 12:03 PM, rosea grammostola rosea.grammost...@gmail.com wrote: When ladish studio is being saved, applications that are run at level 1 receive the SIGUSR1 UNIX signal. How does an application indicate that it intends to run at level 1? Currently an app cannot do it at software level. The level 1 support just needs to be documented. In future, what levels are supported will be indicated by fields in the .desktop files. Until then users are supposed to know whether given app supports given level and indicate it when they start the app. This is done by a radio button selection in the gladish app start dialog. The dialog can be seen in the ladish-0.2 demonstration video at 0:52: http://www.vimeo.com/8530340 -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp7T7h8HCHtf.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: On Fri, Jan 8, 2010 at 10:36 AM, Nedko Arnaudov ne...@arnaudov.name wrote: Currently an app cannot do it at software level. The level 1 support just needs to be documented. What I mean is: if the user starts an application that has no knowledge of LADI at all, and they check the level 1 box in ladish, is that application then guaranteed to crash on session save and lose their data because of an unhandled signal? If user checks level 1 in ladish when starting the app, then ladish will send SIGUSR1 to the app. If the app actually does not support level 1, signal will be sent and chances are that default signal handler will be executed. The default signal handler is to terminate the app. Or will ladish (and/or LADI) only attempt to notify via signal those applications that have registered with LADI in some way? (i.e. level 1 means aware of LADI but that's as far as it goes) Applications cannot register themself yet. This will be possible in future through fileds in the .desktop files. ladish will send SIGUSR1 on save for apps that have been started with level 1 radio button selected by user. For app level 1 means app will save its state when SIGUSR1 is received. Level 0 means app is usable in ladish but user will have to save manually the internal state (it it exists). All JACK apps are supposed to work inladish out of the box at level 0. So far we've found only one that doesnt, beatrix. The problem was caused by the inability of beatrix to run with current directory different from the one where the beatrix executable is. There is a context-less (because of the license) patch for beatrix that fixes this problem. The other problem with some apps is fail of connection restoration for alsa seq ports. The problem is caused by alsa client name being different each time. QSynth does this for example. This is issue only with alsa seq clients. JACK clients work because they are associated with the started app through the pid and not by name. The alsa seq support in ladish relies on a2jmidid. ladish patches only jack midi connections. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpIj3lMKkLh3.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: On Fri, Jan 8, 2010 at 11:00 AM, Nedko Arnaudov ne...@arnaudov.name wrote: Chris Cannam can...@all-day-breakfast.com writes: What I mean is: if the user starts an application that has no knowledge of LADI at all, and they check the level 1 box in ladish, is that application then guaranteed to crash on session save and lose their data because of an unhandled signal? If user checks level 1 in ladish when starting the app, then ladish will send SIGUSR1 to the app. If the app actually does not support level 1, signal will be sent and chances are that default signal handler will be executed. The default signal handler is to terminate the app. That sounds rather hazardous to me. To lose all of one's data instead of saving it, after a potentially long session's work, because of a check box incorrectly checked when starting the session, surely wouldn't please many users? Please take a look at the video. You are wrong. The radio button is selected when app is started for first time, not when session is started. Applications cannot register themself yet. I think I must have misunderstood the use of D-BUS here, then. I had thought that LADI was a D-BUS service which the application connected to, so that LADI would know whether an application was running in a LADI-aware state or not. This is a myth. I've explained what D-Bus usage in ladish (and LASH) is in a recent mail to this mailing list. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpDzuYBTETFB.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: On Fri, Jan 8, 2010 at 11:18 AM, Nedko Arnaudov ne...@arnaudov.name wrote: Chris Cannam can...@all-day-breakfast.com writes: That sounds rather hazardous to me. To lose all of one's data instead of saving it, after a potentially long session's work, because of a check box incorrectly checked when starting the session, surely wouldn't please many users? Please take a look at the video. You are wrong. The radio button is selected when app is started for first time, not when session is started. *boggle* OK... That sounds rather hazardous to me. To lose all of one's data instead of saving it, after a potentially long session's work, because of a check box incorrectly checked when starting the application, surely wouldn't please many users? And you are suggesting what? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpyJ8yZ9vVWY.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: On Fri, Jan 8, 2010 at 11:50 AM, Nedko Arnaudov ne...@arnaudov.name wrote: Chris Cannam can...@all-day-breakfast.com writes: OK... That sounds rather hazardous to me. To lose all of one's data instead of saving it, after a potentially long session's work, because of a check box incorrectly checked when starting the application, surely wouldn't please many users? And you are suggesting what? Uh, I think you've lost me a bit, Nedko. What do I appear to be suggesting? Mmmm, suggesting as proposing I'm just saying that it might not be such a good idea for a session manager to kill applications instead of saving them, when asked to save. Especially if that decision is based on user input that happened a long time ago (so that the user may have done a lot of work since making their mistake, but before discovering it was a mistake). What better alternative you propose? ladish will implement levels 2 and 3 in future. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpQmR6P8JASF.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
rosea grammostola rosea.grammost...@gmail.com writes: Nedko Arnaudov wrote: I'm just saying that it might not be such a good idea for a session manager to kill applications instead of saving them, when asked to save. Especially if that decision is based on user input that happened a long time ago (so that the user may have done a lot of work since making their mistake, but before discovering it was a mistake). What better alternative you propose? ladish will implement levels 2 and 3 in future. I understand the concern of Chris. All though I didn't make the mistake yet when working with Ladish. Isn't it possible to popup some kind of warning message you've chosen level 1, but this is not supported by this app Or another solution which helps the user not making this fault? If ladish knows whether level 1 is really supporeted it wouldnt be needed for user to specify it. Such warning message will be possible when app (.desktop files) list is implemented. But i'd rather disallow user to override the level from the UI, instead user can change the .desktop file or override it with another one in the user specific filesystem location. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpBuavwG1cJY.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Chris Cannam can...@all-day-breakfast.com writes: The procedural difficulty I suppose is that you're trying to get applications to take part in session management without having to get their authors to change them significantly to do so. I can see why that's attractive, but the SIGUSR1 method is still a code change -- it still needs acceptance from developers, a new release of the application, c. Meanwhile, it makes things risky for people who want to continue using applications that don't support it. For my part (and I realise I'm probably inviting the wrath of Fons and others here) I'd probably rather add some D-BUS or equivalent proper message receipt to the application and be done with it. So long as boilerplate code is readily available, that doesn't seem too painful. Yes the goal is to have simple to implement state save message that does not require additional libraries. Whether app developers will implement it is of course their own decision. If their users want it they will have to choose whether to please them or not. If their users don't want it, and they don't like level 1, there is no reason to implement support for it. The problem I have always had with most of the proposed LA session handlers is not so much doing the code as getting around to doing the code, which basically means understanding what the code was supposed to be in the first place -- and I suspect this problem is commonplace, particularly for something like LASH which has always seemed strangely demanding from the code point of view. I dislike the LASH API too. But most importantly LASH requires apps to link to liblash just to restore their connections. This is something that I find... suboptimal. But, I have never tried using ladish and frankly the time taken to write this message is probably about as much as I can afford at the moment. If I don't properly understand its goals, I'm probably just covering ground that you've already covered and reaching conclusions you've already rejected, and I apologise for that. Maybe you can watch the video, it is less than 5 minutes long. (One idle thought is that any proper desktop application is going to have to handle session save already, for the desktop session manager. Can that be exploited?) Desktop session handler traditionally relies on X11. The trend in freedesktop (KDE, GNOME) is to use D-Bus as IPC instead. I'm not aware of D-Bus desktop session manager. Probably, in future, ladish could act as a desktop session manager (via D-Bus or X11) as it is not really limited to JACK apps, it just has some nice features for them. Interracting with the X11 window manager is within the scope of the ladish project. In future, ladish aims to save/restore window properties like window position, virtual desktop and screen (multimonitor). That said, some window managers remember window positions and their virtual desktop out of the box. Some have configurable set of rules for positioning windows isntead. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpkXYEUL0jsB.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Gabriel M. Beddingfield gabrb...@gmail.com writes: Regarding LADI Level 1... In signal handler function, a global variable can be set to mark that save is needed. On next main loop iteration, the global variable is checked and eventually save is made. This totally confused me at first. You're sending me a UNIX signal... but then I'm supposed to answer back by allocating a global variable? How do I do that? It is said set not allocate. I think what you mean is to indicate that saving doesn't have to happen in realtime, but that it can happen (for instance) as part of the program's normal event loop. The stuff about the global variable (or even an event loop) is an implementation detail. I suggest the wording be changed to say something like this: The application, after receiving the signal, should save as soon as possible. However, the saving does not have to happen in the signal-handler function itself. (For example, you can push a 'Save Event' to your normal event loop.) Good wording, thanks! I've updated http://ladish.org/wiki/level1 Save of the internal state can be made in a fixed file path, but it is more useful to supply the file path through commandline. When starting, app loads its internal state from the file specified. When saving, app saves its internal state to the file specified. This is also confusing wording (to me). Who is setting this file path? And the commandline?? I thought we were handling a signal. May I suggest the following wording: The application is free to save state however it sees fit (e.g. saving files to a fixed file path). When the application is started, some means of restoring the state needs to be given to the user, preferably from the commandline. For example, when the signal is received, the application will give a string id (such as a file path) to the user. This id may then be used as a commandline argument to restore the state. Good wording again, I've put it on the wiki page with the correction that needs is replaced with could. There is no need, some apps may want to operate on state in fixed location. I think this is a good idea (Nedko or whoever dreamed it up), and I'm willing to add it to my applications. What are your applications? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpNB4iTiEXY7.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Session Handlers and 'level 1' support
Rui Nuno Capela rn...@rncbc.org writes: On Fri, 8 Jan 2010 09:35:01 +, Chris Cannam wrote: On Mon, Jan 4, 2010 at 12:03 PM, rosea grammostola wrote: When ladish studio is being saved, applications that are run at level 1 receive the SIGUSR1 UNIX signal. How does an application indicate that it intends to run at level 1? good question. i'll add another one: hacking a SIGUSR1 handler is dead-easy, i know, but... how one application gets to know which filename to load/save its state from/to in the context of ladish level 1 session ? Use the current filename. If there is no current filename do what you think is better, either show save as dialog or ignore the signal. Other possibility is to allow supply of non-existent file path to be used for first save in the app. Better make it non-default behaviour because it is somewhat strange if you dont use ladish. I.e. user usually expects start to fail if project file supplied at commandline does not exist. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp940FWNa0H7.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN] LADI Session Handler - Preview 2
The second milestone is reached and result is a tarball that brave souls may want to download and try. It can start apps and restore their connections. Level 1 apps are supported. Beware that no apps have implemented level 1 yet. If non-level-1 app is started at level 1, it will probably quit on save, because the default signal handler for SIGUSR1 terminates the process. This preview also features a2jmidid support. Run the a2j script as an app in the studio. This is a beta quality software, use it with double caution. I would like to thank the early adopters and especially Frank Kober for their help with testing the git ladish code and for the valuable suggestions they gave. Build will produce three operational components: * ladishd - The daemon, a D-Bus service * gladish - GTK GUI interface * ladish_control - Command-line interface In the tarball you will also find bundled: * flowcanvas-0.6.0 * LADI Tools (svn version) * a2jmidid-6 (contains the a2j script for use in ladish) * jack2 from the ladi branch The jack2 ladi branch contains fixes for two important issues: * Race that causes connection restore to fail sometimes during studio startup (http://ladish.org/ticket/28) * A deadlock on studio start (http://ladish.org/ticket/35) Hopefully, these fixes with be in the next jack2 release (1.9.5). The jack2 ladi branch also contains the no-self-connect changeset that adds new engine option, for disabling self connect of apps. Default value for this option is to allow self connections. Make sure to configure jack2 with --dbus (and maybe with --classic too). Download: http://ladish.org/download/ladish-0.2.tar.bz2 http://ladish.org/download/ladish-0.2.tar.bz2.sig Homepage: http://ladish.org/ Roadmap: http://ladish.org/roadmap - LADI Session Handler or simply ladish is a session management system for JACK applications on GNU/Linux. Its aim is to allow you to have many different audio programs running at once, to save their setup, close them down and then easily reload the setup at some other time. ladish doesn't deal with any kind of audio or MIDI data itself; it just runs programs, deals with saving/loading (arbitrary) data and connects JACK ports together. It can also be used to move entire sessions between computers, or post sessions on the Internet for download. Project goals: * Save and restore sets of JACK (audio and MIDI) enabled applications. * Provide JACK clients with virtual hardware ports, so projects can be transfered (or backups restored) between computers running different hardware and backups. * Don't require session handling library to be used. There is no need of such library for restoring connections between JACK clients. * Flow canvas based GUI. Positions of elements on the canvas are saved/restored. * Allow clients to use external storage to save its state. This includes storing internal state to non-filesystem place like memory of a hardware synth. This also includes storing client internal state (client project data) in a way that is not directly bound to ladish project. * Import/export operations, as opposed to save/load. Save/load operate in current system and may cause saving data outside of project itself (external storage). Import/export uses/produces tarball suitable for transferring session data over network to other computer or storing it in a backup archive. * Hierarchical or tag-based organization of projects. * List of JACK applications. Applications are always started through ladish to have restored runtime environment closer to one existed before project save. * Distributed studio - network connected computers. Netjack configuration is part of the studio and thus is saved/restored. * Collaborate with the X11 window manager so window properties like window position, virtual desktop and screen (multimonitor) are saved/restored. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpK0uGpQ7r48.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jack_mixer, resp. PID in JACK client names in general
Ralf Mardorf ralf.mard...@alice-dsl.net writes: Pardon, I won't write so frequently. I compiled a lot of new apps and started making music. Just a short request. Please coders, avoid using the PID in JACK client names. I like to restore sessions automatically by Qtractor or jack_snapshot. I like jack_mixer a lot, but can't use it, because of the PID in the JACK client's name and there seems to be no option to ban this behaviour. Please submit a bug in the bugtracker. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpY4mWFtPuRq.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN] a2jmidid version 6 Indzhe Voyvoda released
a2jmidid is a project that aims to ease usage of legacy ALSA sequencer applications, in a JACK MIDI enabled system. Homepage with screenshots: http://home.gna.org/a2jmidid/ Tarball download: http://download.gna.org/a2jmidid/ Changes since version 5: * MIDI processing improvements * Handle large number of ports * a2j script (non-dbus-like behaviour for dbus environment) * Allow tweaking through dbus of the hardware port export option * Fix a use of invalid memory * Fix port miss that can occur if port appears during bridge startup Special thanks to Torben Hohn and Paul Davis for their recent work on improving the a2jmidid code. Indzhe Voyvoda was a renowned leader of an armed band of outlaws in Ottoman-held Bulgaria. Eventually, he gave up robbing and began to patronize the poor Bulgarian population. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpDXH3dRspt8.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LADI
rosea grammostola rosea.grammost...@gmail.com writes: Nedko, is LADI an project of your own, or are you willing to collaborate with other developers who might have interest in the project? Do I understand it right that characteristics of LADI are still open for discussion? LADI is a project that I started about two years ago. While it is me that is mainly driving it, it is not some kind of dictatorship. In past, several devlopers have contributed code and even more users have contributed ideas and provided feedback. Progress of the project brought some well defined properties of the LADI system. While they can be changed for sure, a large part of the involved people needs to agree. As I, for good or bad, am playing the role of the leader of this thing, I am responsible for decisions that affect the viability of the LADI system. Hopefully this explains why my statements about some subjects are so strong sometimes. It is good for the LADI project to have more active developers. As a developer of this project, I've collaborated with different people from the LAD community, and the result was almost always good. Maybe it aint that bad to have two types of Session handlers for Linux. The LADI approach and another approach without D-Bus. It's not bad to have choice as user and maybe someone needs the features of LADI and others features of more minimal session handlers. It is always better to have more software to choose from. Unfortunately, the reasons for so called competition in open source projects is often working against users, because of the NIH (Not Invented Here) syndrome and the SEP (Somebody Else's Problem) effect. I would really like to beleive that I am wrong. And I would like LAD community to be less stagnant and more open for new ideas and different perspectives. Till now, LADI seems to be the only project that has reach an status so that it actually works and is useful for musicians. Other projects seems to be ideas on paper, nothing practical useful yet. As a user I'm hoping that LADI will become an success, cause at the end we really need an workable session handler. On the other hand I also hope that people like Fons, Bob, Torben and David are able to release an session handler without D-Bus. They have proven to have good ideas and programming skills. I also hope that this will happen. More software we have, more value this community has. Lets favour software creation instead of busting flame wars. I think it will be good to have as much as consensus and especially collaboration as possible. It would be good if others join the LADI project I think. But I can't say which project goals are somewhat close to the LADI project goals. Someone said that Torbens ideas could be implemented or used in LADI in some way maybe. Then it would be good maybe, to have a good (privat) discussion between the developers (at least Nedko seems to say he stands open for that). Yes I am open, as long as it is not at cost of killing the whole project. One of the other projects I've started, zynjacku, is an example of how project direction has shifted without sacrificing the original goals. And this shift happened because of the community. Zynjacku got more improvements for LV2 plugins with static set of ports and custom GUIs (like calf and invada plugins) than it got for dynparam generic GUIs (the lv2zynadd plugin). Весела Коледа Merry Christmas Joyeux Noël -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpkmDHKGy8Wh.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
Bob Ham r...@bash.sh writes: On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov wrote: Hi Bob, thanks for commenting on LADI stuff The huge, major weak point that would prevent me from investing myself in LADI is the use of D-Bus which requires an extra, external layer in order to perform routing between objects on different buses. See my previous mail on the subject here: http://lalists.stanford.edu/lad/2009/11/0350.html From what Nedko has said on IRC, I believe LADISH has such a layer. D-Bus *can* span over multiple hosts. The main issue isn't whether D-Bus clients can connect to buses on a different host. The main issue is whether D-Bus clients connected to one bus can send messages to objects on a different bus. Applications can connect to multiple buses. Even applications that don't interract with remote machines do it. There are two standard local buses, the session bus and the system bus. Here is a screenshot of a dbus application called d-feet that shows two buses connected: http://www.j5live.com/wp-content/uploads/2007/12/d-feet-016-execute.png I was actually labouring under the impression that D-Bus as-is could cope with connecting to remote hosts because it uses sockets. That this isn't the case is, in fact *another* problem with D-Bus. D-Bus clients can't send messages to objects on remote buses. As-is, they can't even connect to buses on remote hosts. Shocking. I already replied to this: http://lalists.stanford.edu/lad/2009/12/0296.html -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgptRE5h3zwD0.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
Louigi Verona louigi.ver...@gmail.com writes: I am relatively new to linux audio, so I would be grateful if you would explain to me the benefits of modular environment. Assuming that you mean modular environment in the sense of LADI as opposed to the sense of plugins (LV2) in a single host, one of the advantages is that with LV2 plugins, bad plugin will bring your whole app down. With multiple JACK apps approach and a session handled, only single JACK plugin crashes. You can still save the work, and even restart (manually or automatically) the crashed JACK plugin. This is not the case with some all-in-one applications for Windows. They use SEH (Structured Exception Handling) to display warning to user and recommend him to save his work and restsart the app. SEH patent expires in 2016. Since Windows XP there seems to be something new, VEH (Vectored Exception Handling) that is also patented, expires in 2023. I'm not aware of exception handling alternative for Linux. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpha3oCVY8BM.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI user question
Ralf Mardorf ralf.mard...@alice-dsl.net writes:
Hi Nedko :)
Hi Ralf
today I tried to compile LADI, but it failed for openSuse 11.2 x86_64
and 64 Studio 3.0-beta3 x86_64. Please take a look at the attachments.
[snip configuring and compiling ladish stuff]
[ 4/41] cc: jack_proxy.c - build/default/jack_proxy_1.o
cc1: warnings being treated as errors
../jack_proxy.c: In function вЂ.jack_proxy_set_parameter_value’:
../jack_proxy.c:588: error: вЂ.type’ may be used uninitialized in this
function
Waf: Leaving directory `/usr/src/ladish-0.1/build'
Build failed
- task failed (err #1):
{task: cc jack_proxy.c - jack_proxy_1.o}
This is an problem that I only recently got aware of. I saw it when I
switched to gentoo and shortly after, I got reports from users. It seems
to happen only for some gcc or something. You reported that it builds
fine on 64 Studio 3.0-beta3 and someone else reported that it builds
fine on Debian lenny. Those warnings (treated as errors) are fixed in
git and I've made a patch (attached) against ladish-0.1 too.
Next preview release of ladish will not treat warnings as errors.
[snip configuring and compiling flowcanvas with warnings]
It looks that flowcanvas is incuding headers in wrong order or
something. These warnings can be ignored without any harm and as long as
it compiles and flowcanvas is maintained externally, there is no urge
for me to fix them.
diff -ru ladish-0.1.orig/daemon/studio.c ladish-0.1/daemon/studio.c
--- ladish-0.1.orig/daemon/studio.c 2009-08-31 04:17:50.0 +0300
+++ ladish-0.1/daemon/studio.c 2009-11-20 01:59:08.0 +0200
@@ -872,7 +872,7 @@
char * p;
const char * src;
char * filename_ptr;
- char * backup_filename_ptr;
+ char * backup_filename_ptr = NULL;
len_dir = strlen(g_studios_dir);
Only in ladish-0.1/daemon: studio.c~
diff -ru ladish-0.1.orig/jack_proxy.c ladish-0.1/jack_proxy.c
--- ladish-0.1.orig/jack_proxy.c 2009-08-27 23:01:58.0 +0300
+++ ladish-0.1/jack_proxy.c 2009-11-20 01:58:36.0 +0200
@@ -585,7 +585,7 @@
value_ptr = boolean;
break;
default:
-lash_error(Unknown jack parameter type %i, (int)type);
+lash_error(Unknown jack parameter type %i, (int)parameter_ptr-type);
return false;
}
--
Nedko Arnaudov GnuPG KeyID: DE1716B0
pgpgT5CDsXeDV.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
Ralf Mardorf ralf.mard...@alice-dsl.net writes: I don't know what exactly it can handle. Which apps can be handled by LADI? What needs to be set up for the apps? In other words, will it really handle a session or just some points of a session? I once tested LASH and it wasn't able to handle anything I need. Without much knowledge about writing shell scripts, I'm able to launch wanted apps and restore connections, not the perfect way I would like to have, e.g. because I still need to place the windows, but without trouble, while e.g LASH does not do this this job, maybe because I missed to google for hours to learn the basics about LASH. Currently it is not yet able to manage sessions at all. What it can is everything else (from the list i've mentioned) except the port virtualization stuff that I plan to implement in ladish. It will be able to relaunch apps, and connect their ports. It will (and already is) able to do some other related stuff. Are there packages or do I have to compile it by solving a dependency hell? I guess, this depends on the distro you use. I recently suitched to gentoo and I made ebuilds for it. In past I've contributed jack2, laditools and lash-0.6.x deb packages to ubuntustudio team. How will it handle a session when some audio apps tend to crash on my machine? Will this cause trouble for LADI? Is LADI some kind of program that will run during the session or will it just run similar to a shell script just to launch and restore a set up, resp. just when saving a set up? When using a session handler, will it be possible that an app that normally is stable, become unstable? It will handle them nicely. It will display notification that app crash was detected and will ask you whether to relaunch it, unless you want it never or always to do so (user configurable option). When relaunched jack ports associated with the application will get reconnected and its internal state will get restored (given that app has internal state and supports restoration of internal state). Internal state and connections will be restored from the last saved snapshot. I'm willing to give LADI a chance and try to add it to my 64 Studio 3.0-beta3 x86_64 and openSUSE 11.2 x86_64. I'm willing to spend some hours to google and read about LADI. *But* I'm not willing to troubleshoot any problems, if it would make handling my sessions more difficult, than it would be without a, resp. this session handler. I guess I can try to add LADI this week to my Linux installs :). LADI is still not able to do session management. ladish can do jack multiconfig however. laditools allow you quite a lot of things regarding JACK monitoring and management. Currently LADI is [mostly] tested by me only. If you are affraid of being early adopter, you should probably not do test it until contributions of other early adopters make it more suitable for you. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpgF9RV7V3vo.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] LADI
that this attempt was probably wrong, with the only excepton of jack2 (Stephane Letz) who accepted my jackdbus development into jack2 and we worked toghether on improving it and on the more general control API initiative. The jackdbus code, my first contribution, that is supposed to improve this mess was rejected by Paul Davis whom maintains jack1. I've got some patches accepted by Patchage`s author and maintainer, Dave Robillard, but they were rather cosmetic ones. This forced me to maintain a software branch (Dave calls it a fork) called lpatchage. It was supposed to be dashboard for the JACK system. I also actively participated in lash-0.6.x development. The only other developper, Juuso Alasuutari, shared some of my ideas, but at the end we ended with fundamental differences about how session handling should behave and what lash should become. As part of my LADI efforts, two people where very helpful. Marc-Olivier Barre and I managed to create pyjackctl, later renamed to laditools. It is set of minimalistic but very useful control apps for JACK, a2jmidid and LASH/ladish. Krzysztof Foltman helped a lot with probably the most complex app in the laditools suite, ladiconf. I'd like to mention people with whom collaboration, even if attempted by me was non-existing: Rui Nuno Capela and Bob Ham. They clearly declared From start that wont help for various reasons and I appreciate this. Because this saved my precious time of part-time contributor to Linux Audio. In May/June this year, Fons Andriaensen got hit by a forcibly packaged jackdbus (i'd call it mispackaging of jack) and started a flame war against D-Bus evilness. I tried to be constructive until I got message From the packager that dbus was forced, even given that he earlier stated that he explicitly enabled dbus support in that package for one reason or another. In June this year, it become evident that I'm not able to contribute to LASH anymore and that I want something else. I left the LASH project and started a new session manager, ladish (project page is at ladish.org). The first preview was released not long after. It was not yet a real session manager but it was able to save and restore multiple jack configs, a foundation for what I call studio in ladish. Since then I've implemented some more stuff and I was hoping that next preview that will be able to relaunch applications and restore connections between their jack ports will be ready by the end of this year. In recent few months, I had less time to contribute to ladish and development slowed. The anti-dbus statements from various people continued almost always without real argumentation behind them. For these that were complains about dbus problems in real setups, I've given suggestions. Almost always I got ignorace and more anti-dbus statements in return. Maybe what I did is really unusable by others, despite it being obviously usable by me. Maybe I suck at trying to help support people who seem to think that ladi is not that bad. Or maybe D-Bus is indeed evil and eats babies and I fail to understand why, even after I've listen to so many arguments. Or maybe there are happy people using jackdbus and laditools (or even lash-0.6.x) and looking toward ladish. But I dont see them. If community does not share my frustration with problems of the JACK system I mentioned above and does not accept my vision that D-Bus is just the most suitable (but not perfect) technology for what I'm trying to achieve, then it would be better for everybody if I don't contribute anymore. I can detach from the community and I can even detach from linux and even computers. So now is the time to give your positive feedback and constructive critics. Don't troll and don't start another flame war unless your goal is to alienate me to stage of me detaching from this community. I will not respond to trolish and flamish mails, feel free to contact me with private mails if you prefer so. As I'm cross posting this mail, if you are subscribed to more than one of the mailing lists, please reply only to one of them. In order of preference, lad, lau, jack-devel. This should avoid discussions half-shared between lists. If they happen at all. This mail is not supposed to be offensive to anyone. If someone feels so, I declare that offense is not intentional. I don't deny the right of different opinion on any subject and thus I have no reason to burn witches. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpVkLfzd3D79.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Undesirable float detector ?
f...@kokkinizita.net writes: Hello all, Did anybody ever write a utulity to detect or count denormals, NaN, Inf, etc. in a Jack stream ? JACK bitscope -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpijkDivnFTW.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Undesirable float detector ?
Nedko Arnaudov ne...@arnaudov.name writes: f...@kokkinizita.net writes: Hello all, Did anybody ever write a utulity to detect or count denormals, NaN, Inf, etc. in a Jack stream ? JACK bitscope That is now renamed to JACK Bitmeter http://users.ecs.soton.ac.uk/njl98r/code/audio/ -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpMRwkwmuId2.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
Nedko Arnaudov ne...@arnaudov.name writes: zynjacku-5 (synth host): rtmempool - http://home.gna.org/lv2dynparam/rtmempool/v1 uri_map - http://lv2plug.in/ns/ext/uri-map event ports - http://lv2plug.in/ns/ext/event dynparams - http://home.gna.org/lv2dynparam/v1 contexts - http://lv2plug.in/ns/dev/contexts msgcontext - http://lv2plug.in/ns/dev/contexts#MessageContext stringport - http://lv2plug.in/ns/dev/string-port#StringTransfer progress - http://lv2plug.in/ns/dev/progress external_ui - http://lv2plug.in/ns/extensions/ui#external gtk_ui - http://lv2plug.in/ns/extensions/ui#GtkUI; dynmanifest - http://naspro.atheme.org/rdf/old-dman#DynManifest As Gabriel spotted, I've missed some obvious extensions: midi_event - http://lv2plug.in/ns/ext/midi#MidiEvent midi_port - http://ll-plugins.nongnu.org/lv2/ext/MidiPort midi_port is deprecated, midi_event should be used for new plugins. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpZWo77llvBv.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
David Robillard d...@drobilla.net writes: On Mon, 2009-11-09 at 23:46 +0200, Nedko Arnaudov wrote: Thorsten Wilms t...@freenet.de writes: Hi! So here's a preliminary zynjacku.ttl attached. I would really like to see http://lv2plug.in/ns/dev/host-info#sinceVersion used, but that would be left to Nedko in this case. Or a source/release archaeologist. Though, there's a question: one ttl per host, or per host version? I already have zynjacku.rdf that is an application/xml+rdf I dont want to maintain two versions of almost same metadata. rapper cannot convert properly between the two. Of course it can. Why not? It changes the order ot triples. I agree that it should not matter and tools should be smarter. Still this does not solve the problem. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpHAAJM7NB7A.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
David Robillard d...@drobilla.net writes: On Tue, 2009-11-10 at 00:25 +0200, Nedko Arnaudov wrote: David Robillard d...@drobilla.net writes: On Mon, 2009-11-09 at 23:46 +0200, Nedko Arnaudov wrote: Thorsten Wilms t...@freenet.de writes: Hi! So here's a preliminary zynjacku.ttl attached. I would really like to see http://lv2plug.in/ns/dev/host-info#sinceVersion used, but that would be left to Nedko in this case. Or a source/release archaeologist. Though, there's a question: one ttl per host, or per host version? I already have zynjacku.rdf that is an application/xml+rdf I dont want to maintain two versions of almost same metadata. rapper cannot convert properly between the two. Of course it can. Why not? It changes the order ot triples. I agree that it should not matter and tools should be smarter. Still this does not solve the problem. What tool actually cares about this? I use this plugin: https://addons.mozilla.org/en-US/firefox/addon/3886 It displays doap through http://sparql.captsolo.net/browser/browser.py Compare http://sparql.captsolo.net/browser/browser.py?url=http%3A//home.gna.org/zynjacku/zynjacku.rdf with http://sparql.captsolo.net/browser/browser.py?url=http%3A%2F%2Fnedko.arnaudov.name%2Fzynjacku.rdf The later one is generated from turtle. At first glance it looks that rapper sorts the entries. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpi9DIugshJv.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
David Robillard d...@drobilla.net writes: Some random web tool having a crappy output layout format is hardly the fault of LV2, raptor, Turtle, or anything else but that tool, obviously. Yes, I got that the tool I use is crappy. How ignoring the problem solves it? I havent said that it is LV2 fault. I complained about evident turtle/xmlrdf schism. And I declared that I dont want to participate in web 2.0 wars. I have better things to do. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpbUTvhlI06X.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
David Robillard d...@drobilla.net writes: On Tue, 2009-11-10 at 00:41 +0200, Nedko Arnaudov wrote: David Robillard d...@drobilla.net writes: Some random web tool having a crappy output layout format is hardly the fault of LV2, raptor, Turtle, or anything else but that tool, obviously. Yes, I got that the tool I use is crappy. How ignoring the problem solves it? I havent said that it is LV2 fault. I complained about evident turtle/xmlrdf schism. And I declared that I dont want to participate in web 2.0 wars. I have better things to do. I don't know. Perhaps there is a better visualizer out there? If you are attached to this thing and consider it important (for some reason I really don't understand) then just maintain the document in a way that works well with it and automatically convert to turtle, instead of the other way around. As far as the 'schism' goes, turtle is a W3C 'team submission' now, on track to be a recommendation with a registered MIME type and all that. Support is pretty widespread, and increasing. It's not really a schism, absolutely everybody despises the mess that is rdf/xml ;) Thanks for being constructive. I've used doap:implements to link project with host applications. Is it appropriate? Here is the output of rapper, contains some strange stuff but the host-info seems to be fine. http://svn.gna.org/viewcvs/*checkout*/zynjacku/website/zynjacku.ttl?rev=203 If this ttl is suitable for use in the extension matrix, I'll dig the changelog and describe extension support changes though releases. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpP4rbhL5OBO.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
Here is what should be (IMO) with current extension list (as i know it): Gabriel M. Beddingfield gabr...@teuton.org writes: FOR SYNTH HOSTS: If you follow these guidelines, you may call yourself an LV2 Synth Host and you will be able to work cleanly with every synth that calls itself an LV2 Synth Plugin. + Support (at least) extensions A, B, and C. * the MIDI event extension * the Event port extension * the URI map extension * the external UI extension GTK hosts must support the GTK UI extension + The synths will have several MIDI input ports (for note data) and several audio output ports. + All configuration will be done with the events extension. + All feedback will be done with the events extension. currently, parameter ports and monitor control (float) ports are supposed to be used for this. event ports could be used for parameter and monitor events but i'm not aware of someone using them for this purpose. + The plugins may provide a GUI interface. Its width will be 200, 400, 600, or 800 pixels. Its height will be a multiple of 100 pixels. I don't get why such restriction is needed. FOR SYNTH PLUGINS: -- If you follow these guidelines, you may call yourself an LV2 Synth Plugin and you will be able to work cleanly with every host that calls itself an LV2 Synth Host. + Freely use extensions A, B, and C. If you use any extra LV2 extensions, try to make them optional. Otherwise, please simply call yourself an LV2 Plugin, because you won't work with every LV2 Synth Host. Plugin author can assume that these are available: * the MIDI event extension * the Event port extension * the URI map extension Plugin author can assume that one of these are available: * the external UI extension (toolkit agnostic, always a window) * the GTK UI extension (gtk specific, may be embeded) + Provide several MIDI in-ports for note data, and several audio out-ports. + All configuration will be done with the events extension. (This does not prohibit you from also doing the same over MIDI) + All feedback will be done with the events extension. + You are encouraged to create a GUI for your plugin. Its width shall be 200, 400, 600, or 800 pixels. Its height shall be a multiple of 100 pixels. See comments for matching guidines for hosts above. UI extensions are of course optional but hosts will handle this gracefully anyway, as defined by LV2 itself. I.e. if plugin provides no GUI, then host will probably use generic one (prefered) or will not allow parameter tweak. If host does not support these GUI extensions, it will not show the GUIs. That said, most users expect plugins to have GUIs, and GUIs running on same host as the DSP code. Some words about the GUI extension problems. If we want (we do, right?) wider adoption of LV2, GUIs must be toolkit agnostic and at least C++ SDK must be provided. External UI may not be perfect but IMO (obviously) it is the best we have in this direction. The GTK extension could be supported automagically if plugin author inherits its GUI class from the GTK plugin GUI base class. proposed class hierarchy: lv2_plugin_base / \ / \ / \ / \ lv2_synth_plugin lv2_effect_plugin | | mysynth myeffect lv2_plugin_base implements the base lv2 plugin functionality lv2_synth_plugin implements the lv2 synth functionality lv2_effect_plugin implements the lv2 effect functionality lv2_ui_base /\ / \ /\ lv2_gtk_ui_base lv2_external_ui_base \ / | \ \ /|\ \ / | \ \ / | \ \ / | \ lv2_gtk2_gui lv2_qt4_gui lv2_fltk2_gui | || mygtkui myqtui mygltkui lv2_ui_base implements the base UI extension lv2_gtk_ui_base implements the GTK variant of the UI extension lv2_external_ui_base implements the external variant of the UI extension lv2_gtk2_gui implements the base functionality of a GTK GUI lv2_qt4_gui implements the base functionality of a QT4 GUI lv2_fltk2_gui implements the base functionality of a FLTK2 GUI Current problems with the UI extension (both gtk and external variants): * there is no easy way for UI to know the sample rate * it is incompatible with lv2core revision 3 If new UI extension is designed, it should probably use event ports. When the original UI extension was designed, event port extension was not avialable. Of course, others are free to disagree. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpwkLdhtWjBj.pgp Description: PGP signature
Re: [LAD] How to develop guis for LV2?
Gabriel M. Beddingfield gabr...@teuton.org writes: Thanks Nedko On Sun, 8 Nov 2009, Nedko Arnaudov wrote: + Support (at least) extensions A, B, and C. * the MIDI event extension * the Event port extension * the URI map extension * the external UI extension What about the dynparam extension? That seems appropriate to require from a synth host. It seems to be quite unpopular. As for Ingen+zynadd, the biggest problem is how Ingen will handle 100+ parameter ports. If they are all automatable, of course. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgptBHFliNxst.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
Chris Cannam can...@all-day-breakfast.com writes: On Sun, Nov 8, 2009 at 6:59 PM, David Robillard d...@drobilla.net wrote: On Sun, 2009-11-08 at 17:46 +, Chris Cannam wrote: likely there is a way to make this work Yay , though obviously not with the existing GTK UI extension. Why not? Because it passes a GTK window, doesn't it? (Doesn't it?) Which has no meaning anywhere except GTK. It passes GTK *widget*. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpRSaUYfF8g0.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
David Robillard d...@drobilla.net writes: Easy documentation about which hosts support what is indeed useful, but you can't come up with a consensus about what hosts should support. They should support everything ;) It's what they DO support that matters. There's been far, far, far too much yapping about this on the list at this point. Yes, we need a compatibility matrix or something along those lines. Everyone agrees. There is really no need to continually state it. SOMEONE MAKE ONE ON THE DAMNED WIKI THEN The problem is simply a lack of documentation. The solution is to write it. There is certainly no utility in complaining about these problems at this point. Those who can do, those who can't complain. Since there seem to be several people who are really, really into this problem solve it already. Using mediawiki is not difficult. IMO, it is much more appropriate to provide this information primary at the plugin/host web sites. Providing it at lv2plug.in site is nice but I doubt it will be the place where ppl will look first. Also please note that this can be integrated at apps.linuxaudio.org. IMHO, the two basic questions that user will have are: 1. Will the plugin X that I use a lot work on host Y that I want to try? 2. Will the host W that I use a lot work well with the plugin Z I've found? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpDwVihvBW4C.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] List of LV2 hosts, plugins and features, add yours here
zynjacku-5 (synth host): rtmempool - http://home.gna.org/lv2dynparam/rtmempool/v1 uri_map - http://lv2plug.in/ns/ext/uri-map event ports - http://lv2plug.in/ns/ext/event dynparams - http://home.gna.org/lv2dynparam/v1 contexts - http://lv2plug.in/ns/dev/contexts msgcontext - http://lv2plug.in/ns/dev/contexts#MessageContext stringport - http://lv2plug.in/ns/dev/string-port#StringTransfer progress - http://lv2plug.in/ns/dev/progress external_ui - http://lv2plug.in/ns/extensions/ui#external gtk_ui - http://lv2plug.in/ns/extensions/ui#GtkUI; dynmanifest - http://naspro.atheme.org/rdf/old-dman#DynManifest lv2rack-5 (effect host): rtmempool - http://home.gna.org/lv2dynparam/rtmempool/v1 dynparams - http://home.gna.org/lv2dynparam/v1 contexts - http://lv2plug.in/ns/dev/contexts msgcontext - http://lv2plug.in/ns/dev/contexts#MessageContext stringport - http://lv2plug.in/ns/dev/string-port#StringTransfer progress - http://lv2plug.in/ns/dev/progress external_ui - http://lv2plug.in/ns/extensions/ui#external gtk_ui - http://lv2plug.in/ns/extensions/ui#GtkUI; dynmanifest - http://naspro.atheme.org/rdf/old-dman#DynManifest Notes: * For both zynjacku and lv2rack, dynparams and rtmempool (currently part of dynparams) extensions are available only if configure detected them. * Dynmanifest support in version 5 (and maybe even for latest git) is for an old version of dynmanifest. * The context, msgcontext and stringport extension support may be suboptimal. It was introduced in order to support calf plugins. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgph4ivTpAOI4.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] dynmanifest, was Re: List of LV2 hosts, plugins and features, add yours here
Chris Cannam can...@all-day-breakfast.com writes: On Sun, Nov 8, 2009 at 8:57 PM, Stefano D'Angelo zanga.m...@gmail.com wrote: 2009/11/8 Nedko Arnaudov ne...@arnaudov.name: * Dynmanifest support in version 5 (and maybe even for latest git) is for an old version of dynmanifest. Git version is for the current version ;-) What is dynmanifest? I can't see it in the wiki. (changing subject line to avoid polluting thread) http://lv2plug.in/ns/dev/dyn-manifest.lv2/dyn-manifest.html (first hit in google) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgps7P9h20o6i.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] dynmanifest, was Re: List of LV2 hosts, plugins and features, add yours here
Chris Cannam can...@all-day-breakfast.com writes: On Sun, Nov 8, 2009 at 9:03 PM, Nedko Arnaudov ne...@arnaudov.name wrote: Chris Cannam can...@all-day-breakfast.com writes: On Sun, Nov 8, 2009 at 8:57 PM, Stefano D'Angelo zanga.m...@gmail.com wrote: 2009/11/8 Nedko Arnaudov ne...@arnaudov.name: * Dynmanifest support in version 5 (and maybe even for latest git) is for an old version of dynmanifest. Git version is for the current version ;-) What is dynmanifest? I can't see it in the wiki. (changing subject line to avoid polluting thread) http://lv2plug.in/ns/dev/dyn-manifest.lv2/dyn-manifest.html (first hit in google) I see. I understand from this that it's a dynamic manifest generator. What is a dynamic manifest generator? NASPRO presents (or will present) LADSPA/DSSI/VST plugins as LV2 plugins. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpjaZkP6STyl.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] remote dbus and ladish. Was: gets confused when used through ssh -X
Patrick Shirkey pshir...@boosthardware.com writes: I don't see much point of storing a local copy of a ssh tunneled config file. If you are tunnelling the config file should be accessed from the remote machine. It's different if you are using multiple qjackctls on the same desktop and connecting to local jackd instance/s as well as netjack'd instances on remote machines. That seems like a heavy deal and as Nedko has mentioned previously it can actually be managed by the LADI tools now although that requires running dbus too which is not to everyones liking. Yesterday, I've booted my wife`s windows machine from an Ubuntu LiveCD and made some remote dbus tests. There are two options to initiate this through ssh. The first one is to start socat[1] at both sides and use tcp for connecting them: dbus app - unix socket - socat - tcp over ethernet - socat - unix socket - dbus daemon - dbus app The other one is to use gabriel [2] at client side. Gabriel uses libssh [3] to setup socat remotely and tunnels the dbus traffic over ssh tunnel: dbus app - unix socket - gabriel - ssh over ethernet - socat - unix socket - dbus daemon - dbus app Gabriel`s approach is of course better in long term, because dbus traffic is encrypted and because it sets remote part automatically. Bad news about gabriel is that last commit is from February 2007, it needs a patch to work with latest libssh (0.3.4) and it allows only one client to use the local unix socket. Both approaches have restriction because of the EXTENRAL dbus authentication mechanism. That mechanism sends unix user id and it is matched remotely. So in order remote dbus to work, uids should be same. Of course this is lame and I already have plan for this: the client side (gabriel/ladish), can get the remote uid through ssh and change the uid token. Plan for the remote capable ladish is to take the gabriel`s approach. Requirements for the remote (aux) hosts will be - ssh server, dbus, jackdbus and socat. Requirements for the local (central) host will be ssh client, libssh, dbus, jackdbus, ladish. ladish will provide dbus service that will act as manager for remote dbus connections. Such service could be reused for other remote dbus purposes and as such could be a separate project (or could be made as part of gabriel). Multihost ladish is planned for the 2.0 release and wont happen anytime soon unless someone with high motivation steps to work on this. I'd like to ask users of multiple-jack-servers-on-same-host (Fons?) to explain what it is used for and how it works. As I personally dont use such setup I can't make ladish suitable for such setups without feedback. Same applies for remote jack management and netjack but I've gathered some knowledge because of the obvious netjack popularity. [1] http://www.dest-unreach.org/socat/ [2] http://gabriel.sourceforge.net/ [3] http://www.libssh.org/ -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpz9dV31Gjsh.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Gabriel M. Beddingfield gabr...@teuton.org writes: Hi guys, I'm looking to delve into the world of plugins (for both synth and fx), and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a little confusing. It appears that LV2 is current, that DSSI is deprecated, and that LADSPA would be deprecated if it weren't so widely adopted. However, LV2 is slow in being adopted. Is this developer resistance... or is it just too new? I think both. Also, I can't find any applications that will host all 3, nor even LV2+DSSI. Is there a technical reason for this? No. OTOH naspro acts as wrapper that presents ladspa and dssi plugins in lv2 world. LV2 covers most if not all features of LADSPA and DSSI but LV2 still misses some important extensions (presets, binary state save/store) that makes it inferior when compared to well established stuff like VST. I think this is one of the reasons of low adoption. The other is that it is just too new (as in not enough plugins/hosts). As it is an open source community project and not driven by an enterprise, its development is slow when community is small and somewhat apathic. Other ppl involved in LV2 stuff may disagree of course. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpsKZFdxo7Dj.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1
Ralf Mardorf ralf.mard...@alice-dsl.net writes: I welcome ladish, but most of the times I would like to have a Linuxsampler DSSI, a Hydrogen DSSI etc. ;). You prefer DSSI over LV2? In recent years I've spent lot of time on both JACK session handling problem and LV2. The two technologies have something in common and have their pros and cons. I think that both are needed. JACK plugins (apps in session handling environment) provide better separatation and allow the developer to do more tricks, it is the more flexible. LV2 plugins provide less overhead, better match the plugin image in users`s heads, but are more restricte. The LV2 GUI problem is especially bad, it slows LV2 adoption because hosts and plugins need to use same GUI toolkit. LV2 External UI extension maybe will fix this, time will tell. Maybe JACK plugins are more viable than LV2 plugins. After all we have more JACK mini-apps than complex LV2+DSSI+LADSPA plugins. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpscJZEOpirH.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] LADI Session Handler - Preview 1
The first milestone is reached and result is a tarball that brave souls may want to download and try. It contains implementation of JACK multiconfig functionality. JACK server settings can be saved as part of a studio. Then, loading studio will cause JACK settings stored as part of the studio to be restored. Build will produce three operational components: * ladishd - The daemon, a D-Bus service * gladish - GTK GUI interface * ladish_control - Command-line interface In the tarball you will also find bundled suitable (latest and gratest) flowcanvas and LADI Tools. Download: http://ladish.org/download/ladish-0.1.tar.bz2 http://ladish.org/download/ladish-0.1.tar.bz2.sig Homepage: http://ladish.org/ Roadmap: http://ladish.org/roadmap - LADI Session Handler or simply ladish is a session management system for JACK applications on GNU/Linux. Its aim is to allow you to have many different audio programs running at once, to save their setup, close them down and then easily reload the setup at some other time. ladish doesn't deal with any kind of audio or MIDI data itself; it just runs programs, deals with saving/loading (arbitrary) data and connects JACK ports together. It can also be used to move entire sessions between computers, or post sessions on the Internet for download. ladish has GUI frontend, gladish, based on lpatchage (LADI Patchage) and the ladish_control command line app for headless operation. LADI Tools is set of apps that interface with ladish, JACK server and a2jmidid ladish requires D-Bus and JACK compiled with D-Bus support. LADI Session Handler is rewrite of LASH. Project goals: * Save and restore sets of JACK (audio and MIDI) enabled applications. * Provide JACK clients with virtual hardware ports, so projects can be transfered (or backups restored) between computers running different hardware and backups. * Don't require session handling library to be used. There is no need of such library for restoring connections between JACK clients. * Flow canvas based GUI. Positions of elements on the canvas are saved/restored. * Allow clients to use external storage to save its state. This includes storing internal state to non-filesystem place like memory of a hardware synth. This also includes storing client internal state (client project data) in a way that is not directly bound to ladish project. * Import/export operations, as opposed to save/load. Save/load operate in current system and may cause saving data outside of project itself (external storage). Import/export uses/produces tarball suitable for transferring session data over network to other computer or storing it in a backup archive. * Hierarchical or tag-based organization of projects. * List of JACK applications. Applications are always started through ladish to have restored runtime environment closer to one existed before project save. * Distributed studio - network connected computers. Netjack configuration is part of the studio and thus is saved/restored. * Collaborate with the X11 window manager so window properties like window position, virtual desktop and screen (multimonitor) are saved/restored. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpPOI3pIiVm3.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1
Julien Claassen jul...@c-lab.de writes: Hello Nedko! I've just got ladish and I'm installing it. I've looked into the requirements. I see there's a lot of GUI and GUI-related, which seems to be required. My question: Could you consider making as much as possible of the GUI-stuff optional. I don't have and I don't need any GUI, so I need to install quite a bit. In any case, the daemon itself doesn't require it, so does the minimum user tool (ladi_control). Making GUI stuff optional is perfectly possible and I like the idea. Do you want to make a patch (or git commit somewhere) for this? the command-line tool is called ladish_control not ladi_control -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpM7kSWV9shj.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1
Julien Claassen jul...@c-lab.de writes: Hello Nedko! Now I've come up against a wall, which I don't want to climb. It's all to do with GUI-toolkits and their relatives. Especially flowcanvas. I dearly hope and plea for the feature, to optionalise the GUI-parts. Flowcanvas seems to require something ese, which is tedious. Because now I could go on installing ad nauseam, without getting anywhere in a short while. Well you might say, that I'm a special case, being blind, having no graphic. But I think this might hit other people as well. People with other main-GUI-toolkits or other commandline friends, and there are some. I'd be glad to know, if you're so far along on your way, that you seperated the GUI parts from the real thing. Kindest regards Julien GUI (gladish) and the real thing (ladishd) are really separated. Later today I'll try to modify the waf build script to support GUI-less build. Here is a ticket for you: http://ladish.org/ticket/10 -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpxFIjb7nYxZ.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1
Jörn Nettingsmeier netti...@folkwang-hochschule.de writes: cool. nedko, not intending to rehash the dbus carnage of yore, but: for a headless system without a user logged in via some graphical desktop, what is needed to be able to run LADI? The DBUS_SESSION_BUS_ADDRESS must contain the address of the session bus daemon. Check the man page of dbus-launch. I launch the session bus daemon from by ~/.xinitrc script (I don't use xdm/kdm/gdm) like this: eval `dbus-launch --sh-syntax --exit-with-session` The man page has more documentation. Countrary to popular beleif, D-Bus is not bound to desktop, in the GUI sense. It does not even make sense for the system bus where HAL and other system stuff lurks. i for one would be interested in having a rudimentary start script that gets all the $FOOkits and dbus-$GIZMOs in place so that LADIsh can work. even if few people will use it on headless systems, it would be very instructive and show how different system services work together. You need to obtain the value for the session bus address on each tty (local or ssh ones for headless operation). If you came with steps for setting such envirnment, please share them - I want them on ladish.org wiki. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpLoiB6VoPaZ.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ANN] LADI Session Handler - Preview 1
Nedko Arnaudov ne...@arnaudov.name writes: Julien Claassen jul...@c-lab.de writes: Hello Nedko! Now I've come up against a wall, which I don't want to climb. It's all to do with GUI-toolkits and their relatives. Especially flowcanvas. I dearly hope and plea for the feature, to optionalise the GUI-parts. Flowcanvas seems to require something ese, which is tedious. Because now I could go on installing ad nauseam, without getting anywhere in a short while. Well you might say, that I'm a special case, being blind, having no graphic. But I think this might hit other people as well. People with other main-GUI-toolkits or other commandline friends, and there are some. I'd be glad to know, if you're so far along on your way, that you seperated the GUI parts from the real thing. Kindest regards Julien GUI (gladish) and the real thing (ladishd) are really separated. Later today I'll try to modify the waf build script to support GUI-less build. Here is a ticket for you: http://ladish.org/ticket/10 The fix is in the git repository. To get the sources with git: git clone -o nedko http://nedko.arnaudov.name/git/ladish.git This will create ladish/ subdirectory where sources will be. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp1Y9RsIlUvm.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0
hollun...@gmx.at writes: The meter doesn't show up in lv2rack. It shows up in ardour2. zynjacku and lv2rack have cache of suitable plugins. Did you rescan the LV2 world after you installed the new version of Invada plugins? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp69OfHrJ8Ys.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jack2's dbus name
Lennart Poettering mz...@0pointer.de writes: On Thu, 18.06.09 16:09, torb...@gmx.de (torb...@gmx.de) wrote: I think org.jackaudio.service should be fine. I don't think this automatic logic needs to work on non-D-Bus jack builds. As I see it you don't need to make any changes on jack for this to work. All I need is the guarantee that by the time the service name is registered on the bus jack is fully accessible. Otherwise we had a race here: if PA looks for the org.jackaudio.service name to appear on the bus and then imemdiately connects to it while jack isn't fully accessible yet PA would fail. the existence of org.jackaudio.service object does not guarantee, that jackd is connectable. I'd consider that brokeness in Jack then. Taking the name on the bus sould be the last step during initialization. Otherwise you'll always be in racy situations where clients try to talk to JACK while JACK is only half-way initialized. I'd like to clarify something, org.jackaudio.service exposes the controller object. It is not the server, it is the controller, a peristent endpoint that can be used to start and stop the server on user request. jack clients are usually not supposed to check whether jack server is started. It will be either autostarted or libjack initialization will fail if autostart is disabled and jack server is stopped. The dbus object name that is used for cooperation with PA is different thing. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpYvuq5rBqbJ.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lv2fil version 2.0 New hope released
Jörn Nettingsmeier netti...@folkwang-hochschule.de writes: hi nedko! Nedko Arnaudov wrote: James Warden warj...@yahoo.com writes: Where's the ardour patch ? Thanks :) http://nedko.arnaudov.name/soft/ardour2-r5126-lv2_external_ui.patch thanks for the lv2 port. since i've read some of fons' code and have a rough idea how it works, i hope this will give me the chance of learning lv2 by example - i'm pretty excited about this... haven't tested the lv2 version yet due to lack of time, but since this patch looks pretty self-contained, do you think it might make sense to push it into the upcoming ardour 2.8.1 release? It is not that clean, but I can clean it more if such cleanup is required for incusion in ardour 2.x. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpyhjUNLK58y.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] zynjacku-5
In this release: * slv2 is no longer required * cache list of suitable plugins * speedup plugin list window * new tool, zynspect, that can be used to list and inspect available lv2 plguins. * Fix assert when restoring rack presets * By default, sort plugins by name * Experimental support for dynmanifest extension. Combined with NASPRO allows loading ladspa plugins in lv2rack. * Set plugin GUI window's role to plugin_ui (for WM kludges etc) * single plugin mode for lv2rack * Hide external UIs when zynjacku/lv2rack quits zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK MIDI input port (routed to all hosted synths) and one (two for stereo synths) JACK audio output port per plugin. Such design provides multi-timbral sound by running several synth plugins. zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid parts for synthesis itself and you have flexible part that allows synthesis to suit your needs. lv2rack is a host for LV2 effect plugins. Project homepage with screenshots: http://home.gna.org/zynjacku/ Get tarball from here: https://gna.org/files/?group=zynjacku -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpKuyWLFOLoV.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] lv2fil version 2.0 New hope released
Four-band parametric equaliser LV2 plugin. DSP code by Fons Adriaensen. Homepage: http://nedko.arnaudov.name/soft/lv2fil/ Screenshot: http://nedko.arnaudov.name/soft/lv2fil/lv2fil.png Tarball download: http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2 http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2.sig = Overview = Stereo and mono LV2 plugins, four-band parametric equalisers. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. = DSP = The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameters are being changed. All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use. = GUI = The GUI provides knobs and toggle buttons for tweaking filter parameters. It also provides frequency response widget with differently coloured curve for each section and separate curve for total equalization effect. The GUI uses the External UI extension. lv2rack (part of zynjacku) supports this extension. Ardour-2.8 needs patch to support the external UI extension. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpIxNiWbmWSz.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lv2fil version 2.0 New hope released
James Warden warj...@yahoo.com writes: Where's the ardour patch ? Thanks :) http://nedko.arnaudov.name/soft/ardour2-r5126-lv2_external_ui.patch -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp7bG2wX7RKK.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack for windows compared to linux
Stéphane Letz l...@grame.fr writes: What do you think Stephane, can native jack clients on windows achieve performance which is almost at par as native ASIO apps ? If we release LinuxSampler with jack support we have probably to ship libjack (otherwise the app does not start) with the sampler and it could be that it conflicts with an already installed jack. Well I also recently had this kind of weak link requirement for libjack on Linux. I think OSX supports some kind of weak linking with any compiled framework, but the situation is less clear on Windows on Linux. A possible solution would be to provide a special libweakjack library with the appropriate bahaviour for that. On Windows, you can use LoadLibrary() API function to load libjack.dll. On Linux, dlopen() can be used to load libjack.so. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpQRR5YNRPM3.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] invada-studio-plugins-lv2-1.0.0
Chris Cannam can...@all-day-breakfast.com writes: Even if it did support LV2, it couldn't support the GUIs because (unless it has changed dramatically since I last looked at it) the LV2 GUI extension is limited to a single host toolkit which Rosegarden does not use, namely GTK. There is external UI extension that allows plugin to launch the GUI in separate process. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpjYhuSP47Tv.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] invada-studio-plugins-lv2-1.0.0
Chris Cannam can...@all-day-breakfast.com writes: On Sun, May 31, 2009 at 11:36 AM, Nedko Arnaudov ne...@arnaudov.name wrote: Invada plugins don't have external UI. If you are going to add LV2 support to Rosegarden I'll add external UI support to Invada. I promise. That is a worthy promise; thank you. But what are the chances of new plugin developers being prepared to do that extra work themselves, as a general matter? (I realise that's a rhetorical question, or at least one you can't be expected to have the answer to. Fraser might have some thoughts, perhaps?) If they are prepared to do DSSI like stuff (the only alternative we have ATM), they can reuse the DSSI-like universal wrapper. The code needs only two defines, UI_EXECUTABLE and UI_URI. If they are not, then maybe they are looking for in-process UI extension that is toolkit independent. I have idea about cairo UI extension but it will require abstracting mouse and keyboard events. Also it will force plugin authors to use some kind of [custom] widget toolkit based on cairo. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpJWlNzmUaVx.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] invada-studio-plugins-lv2-1.0.0
Fraser fra...@arkhostings.com writes: Nedko Arnaudov wrote: Invada plugins don't have external UI. If you are going to add LV2 support to Rosegarden I'll add external UI support to Invada. I promise. At least let me try and fail first. ;) I assumed you have better things to do ;) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpqWBo3tZrk1.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof Foltman wrote: I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or eating babies. Well, the current implementation *does* intercept C API calls in order to divert them to dbus, it's not just an addition to the standard jackd. I never mentioned babies being eaten. As long as interface is same at C API level everything is fine. dbus cant and does not intercept any C API calls. The implementation of the jack_client_open(), only when compiled in dbus model, only when wants to start jack server, starts the jack server by *CALLING* libdbus function. That C level libdbus API call is then implemented by using the dbus IPC mechanism (sockets) and then gets into jackdbus process that executes the call. Nobody is intercepting jack.h API C level calls. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpxGqZN2rJDr.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote: Fons Adriaensen f...@kokkinizita.net writes: Well, the current implementation *does* intercept C API calls in order to divert them to dbus, it's not just an addition to the standard jackd. I never mentioned babies being eaten. As long as interface is same at C API level everything is fine. dbus cant and does not intercept any C API calls. The implementation of the jack_client_open(), only when compiled in dbus model, only when wants to start jack server, starts the jack server by *CALLING* libdbus function. That C level libdbus API call is then implemented by using the dbus IPC mechanism (sockets) and then gets into jackdbus process that executes the call. Nobody is intercepting jack.h API C level calls. Nedko, you continue to contradict yourself. What you write above confirms that the jack_client_open() call is intercepted and its action modified. It is not intercepted. It is implemented. No hooking is made. jack_client_open() action is not modified. It behaves as expected, as documented in the API. jack server is autostarted. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpXWcDRelfok.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote: It is not intercepted. It is implemented. No hooking is made. jack_client_open() action is not modified. It behaves as expected, as documented in the API. jack server is autostarted. It's not just a different implementation. It has side effects that the original call does not have (starting a daemon), and these side effects will have consequences later. If this is not true then the new implementation is actually useless. I would have no objection if you added e.g. jack_client_open_via_dbus() leaving the original call as it is. No and no again. jack clients dont care how jack server is started. they want it started so they can use it. period. they dont care about jack internal infrastructure. The whole point of abstrctions is to allow changing the implementation. As it is with jack1 and jack2. Why you dont want jack_client_open_jackdmp() ? Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. This is a BS, nobody is forcing you to use that. You have the free will. You can choose what to use. There is an option that you dont like. And nobody is telling you that it will enhance *your* life. It may enahnce my life. Or someone else's. But not yours. This is why it is optional. Even installing jack2 instead of jack1 is optional. You are free to use VAX if you like it. Nobody is forcing you to use something else. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpHa1XVhokkf.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Felipe Sateler fsate...@gmail.com writes: Stéphane Letz wrote: My feeling is that is we choose the runtime auto-start strategy, then we should not mix anything concerting setting management This sounds weird to me. There should be only one canonical configuration file for jack, independent of how it was started. What canonical means? Something achieved through massacre? Or something achieved through evolution? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpUZKUy9P8iA.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
torb...@gmx.de writes: so please tell me why the dbus implementation CANT just read .jackdrc ? i am really pissed on all you guys trampling on legacy stuff. It can. Nobody has implemented it. WHY cant jackdbus just use the .jackdrc if it does not find its own .xml config ? or check, whether .jackdrc is newer than the xml ? Because it is useless. It is useless because you will still have two configuration files. You are not solving the problem. qjackctl and ardour will save to jackdrc, jackdbus (or multiconfig object) will save to other file. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpAxqfpQQbIV.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
torb...@gmx.de writes: On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote: however, by having jackdbus in the picture and when everybody would think it would be the holy grail, it is breaking all that instead just because it wants to rule the game on its own. it's doing it with complete disregard to what long time qjackctl/jackd users have been thought. that's disgraceful to say the least. It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't show messages generated by jackd when jackd is autolaunched by regular jack client application? Last time I checked those messages go to application's stdout (that is inherited from the parent process - the one of the normal jack client application). The issue that started this holy war is that dbus enabled package that contains also jackd got into the hands of Fons and ate his babies. The problem is already fixed in svn. qjackctl will not work when dbus is enabled unless both jackdbus and jackd are compiled and installed and after the packager ignores the warning text at configure time. qjackctl will not work because there will be not jackd executable installed. and why is this so complicated ? why not think a bit about legacy ? this i dont care for legacy attitude is the problem. and it does not help to say we think dbus eats babies. this is just a cheap excuse. we are pissed because you dont care. and i am starting to care less and less for all this shit too. I care about legacy. I've implemented a2jmidid to support legacy ALSA seq stuff. I've tried to not obsolete legacy things. But when some part is not designed to cooperate and is not extendable you have to give up. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpgD3AtSXXfC.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] A picture...of the global mess
Stéphane Letz l...@grame.fr writes: He all, A picture to try summary what I understand about we would like : - a new shared library called libjackontrol.so : is does implement the so called control API and a IPC mechanism to use it. - jackcontrol is an *always running deamon that defined an entry IPC point. jackcontrol get requests from control applications. jackcontrol can start a seprated server called jackserver (using a fork+exec) way. jackcontrol is a *unique* place where setting are handled. - jackd is a recoded control application that parse it's command line, and use the control IPC to speak to jackcontrol (then just quits). jackcontrol then start the jackserver whith the appropriate paramaters. - jackddbus is a D-Bus aware control application; It receive DBus requests and translate them to control IPC to speak to jackcontrol. jackcontrol then start the jackserver whith the appropriate paramaters - libjack.so speaks also to jackcontrol using the control IPC: an client that auto-start actually use this mecanism Does it helps? Stephane As alternative diagram we already have the old one: http://www.marcochapeau.org/documentation/jackenv Instead of three IPC layers between pyjack(laditools now), you have only one. I like the architecture described in this diagram. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpH6nY2bATGq.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham r...@bash.sh writes: On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote: Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I think a better analogy would be like so: Someone sets up a firm that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the free service and tell him: - Listen, I don't want you to stop the radiators in my house from working. - That's fine, you're entirely free to install your own plumbing, or fix the plumbing we've installed for you. - I don't want to, you should do it for me and do it right dammit! Even better: Someone sets up a firm Foo that produces furniture, appliances, plumbing, etc. Someone sets up a firm Bar that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home by using the prducts of firm Foo. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the firm Foo and tell him: - Listen, I don't want you to stop the radiators in my house from working. - I don't. I have no control with out. Why you dont ask the manager of firm Bar? - But you produce it! - Yes, we produce toxic waste too. There are bacteria that eat it. I'm affraid the manager of firm Bar got impression that you eat toxic waste too. I'm sorry about situation. We will improve instructions about our toxic waste product but still, you have to request Bar to meet your requirements. Or stop using Bar and use Baz instead. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp4kbu8rH33o.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpiCZR4wckIj.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: Nedko Arnaudov wrote: Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. Watching the jam for free, you can learn a lot, but you don't get the music you might wish to get, you need to go to the concert for free or you need to download the recording for free AND the band can produce different new versions, but it should be possible to hear the first version of the concert in the future ... metaphors won't work ;). The live stream is captured (public repo is persistent) and you can hear the first version in the future. ;) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpmYsb2V8koB.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: The latest version of the Atari Cubase still can run sessions of the first version, sometimes you can't do this with Rosegarden between two versions (okay, I nearly does NO RT-AUDIO with Linux ;)). But the point isn't what is possible or impossible for other OS's. For Windows and Mac you can get the same open source applications, but not everybody want to work with the source code and set up the application by this way, most people needs a working tool. So you blame Steinberg for not releasing new versions of Ableton that will support Linux? ;) Or you blame gnome folks about new KDE being crap? :) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpEsvqPG7UQT.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
MarcO'Chapeau ma...@marcochapeau.org writes: On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen f...@kokkinizita.net wrote: The only argument pro using dbus I'v heard so far is that it permits run-time discovery of new backends, internal clients and their parameters. That's unfair. Read the archives. There are more arguments to that. All features that jackdbus offers can be added without dbus. Using dbus was and still is the best way. It will be the best until there is better reusable model invented. Or if someone donates (development time) to implement such object model. Most important thing missing in jackd is the log file. Then you have other missing features: * no way several app to control single jack server. One needs to adopt it. * no runtime discovery of jack settings * no hierarchical settings file * complex patchbay API that results in complicated code in patchbay apps * multithread (for jack1 realtime too) threading model. (GUI) control patchbay app should be allowed to be single threaded and not required to handle graph change events in a realtime context. Dbus assumes there is a local login, without that there is no session bus, and things don't work. Most of my audio machines are headless, there is no local login, but I still expect things to work, and that, IMHO, is not unreasonable. It is not unreasonable. No one said you *had* to use dbus. This needs fixing and until it is fixed, packagers should be advised to disable dbus. ATM headless and multiserver setups are not covered by jackdbus. This *can* be fixed with dbus model. Packagers tha have made the packages should have read this before enabling dbus: http://trac.jackaudio.org/wiki/JackDbusPackaging Maybe they did. I dont see why you Fons are attacking jackdbus because of packaging not matching your needs. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpe49UcKihQf.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen f...@kokkinizita.net writes: On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* not using the DBUS layer! Then please tell what this is: (ps -ef output) fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto Killing this makes qjackctl behave normally again, and allows me to start the server configured in it Setup window instead of getting a different one. Presence of jackbus process does not mean that jack server is started. It means that jack server may or may not be started. jackdbus service is there to allow in future creation of multiple jack servers. the easiest way to check whether jack server is started by jackdbus service is: jack_control status -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpKR5tgRqVyY.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Paul Davis p...@linuxaudiosystems.com writes: On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz l...@grame.fr wrote: After all these discussions on JACK2, D-Bus and Qjackctl issues, here are some general comments: 1) JACK2 *default* compilation mode defines the same starting scheme at JACK1 was doing. So (beside possible bugs) it is supposed to be completely interchangeable with JACK1. It can be controled with Qjackctl as usual. 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based control application... (jack_control is a simple python example of a control application part of the package). Using JACK2 compiled in D-Bus with Qjackctl is a receipe for trouble, even if if can be done in some simple use cases. (The point is that in this case the client auto-start feature starts the jackdbus exe instead of jackd with all of the related settings issues). 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl bug, so has to be fixed at the right place. I don't see right now any raisonable way to fix this mess, better than adding even more complexity in the design... (Nedko any idea?) Otherwise I guess the only way is to make this totally clear for packagers : 1) is the standard way that maintains complete compatibility with legacy applications and control applications. 2) is the new way to be used with new D-Bus based control application (patchage ??)... So it would mean 2 separated packages. this sounds like a mess. there is a control API. i believe it was agreed that the control API could be accessed directly (from C/C++ etc), or via other systems for which translators/layers were added (e.g. DBus). i can see no reason why anyone would want to use choose between a JACK server that can be controlled via either DBus or the control API but not both. what is going on? ___ Jack-Devel mailing list jack-de...@lists.jackaudio.org http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org Using the dbus ate my babies matra is causing mess because other people don't think so. Using dbus interface in qjackctl would fix lot of this mess and this is the reason I asked Rui about that. Of course dbus ate my babies ppl would see usage of jackdbus in qjackctl as a bad thing. Does qjackctl support headless and multiserver jack setups? How headless setups work? When someone logins through ssh, does it access jackd server that runs as same user? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpxStrb4eEat.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
alex stone compos...@gmail.com writes: So again, i'll ask the question. Will we continue to have a Jack version minus the dbus infrastructure, once jack2 is released? Or are we destined to be dragged into a compulsory hybrid? I share Fon's concerns, and still don't understand why the dbus/pulse momentum is taking precedence over what has been up to now, a great audio solution for any user who wants to write and create music. I'm not a coder, but i'll ask the jack team, who i have a lot of respect for, to take a step back and have another look at the bigger picture again. Dbus may be a way into a partnership with Pulse, but that implies a degree of compulsory requirement for the user. And i don't think answering with So don't use it is an answer if there's a question over the persistence of Dbus and Pulse overriding the users intent. Fon's description of Big Brother seems more applicable, and less humorous, the more one thinks about this. Alex. p.s. I'm practical about software, so the Dbus mantra means nothing to me. There are three packaging scenarios described in http://trac.jackaudio.org/wiki/JackDbusPackaging This document is created packagers can choose how to package jack. The mixed setup is can easily lead to user frustration and this is explained. I personally use the mixed setup but i know how the whole mixed system behaves and I need to start jackd occasionally. I wouldn't recommend packaging mixed setup. In ubuntu packages I've created jackdbus is separate package. jackd is separate package too. They both implement jack server virtual package. Packagers must choose between classic jackd or dbus-only scenarios unless they want to cause pain to their users. Some more things I've implemented in the ubuntu packaging... Only dbus control apps depend on jackdbus package. qjackctl depends on jackd package. So if you install qjackctl but dont want (or dont know about) jackdbus you get no dbus. If you install lpatchage or laditools you get dbus setup. Users don't care about jackd vs jackdbus. They care about the frontends. If they are used to qjackctl+jackd they will use that and will get no dbus ate my babies feeling. If they like ladi control apps, they will not use jackd. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp0X7wVkPLf9.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
Jan Weil jan.w...@web.de writes: On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote: Will we continue to have a Jack version minus the dbus infrastructure, once jack2 is released? As an uninvolved observer I am wondering why the dbus control interface, if it is indeed only one of many potential interfaces using the c/c++ API, is not packaged separately as an optional add-on. If it is indeed a compile time option, the design is flawed IMHO. Generally, the new control API sounds like a good idea but why can't the new features be exposed as new command line tools without dbus dependency per default? So you want the dbus interface? Fine, just install jack-control-dbus or whatever. Or am I not getting it? You are getting it but obviously the one who has put those packages in the respected repository is not getting it. I've packaged jack2 in the way you've mentioned. Of course those are for specific distro (ubuntu) and not real packages but draft packages that i've made to simplify work of real packagers when they take the maintainership. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpFt0RbxCSlK.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
drew Roberts z...@100jamz.com writes: How does dbus know what parameters to start jack with? Where is that configured? (Perhaps this will solve the issue, I don't recall this information passing before my eyes in this thread so far.) jackbus reads the configuration file and then start jack server through the control API. The configuration file is stored in ~/.config/jack/conf.xml (location conforming to the XDG Base Directory Specification). -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpFeIBAMoToM.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes:
On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko Arnaudov wrote:
libjack does not start jack server if JackNoStartServer is
specified. This behaviour is same for both jackd autolaunching and dbus
jack server starting through activation. Presense of the jackdbus
process *DOES NOT MEAN* that jack server is started. It looks like fair
game to me.
This is definitely *not* true. Presence of the 'jackdbus auto'
daemon results in a jackd starting whenever qjackctl is
started, and the author of that app has already reported
that qjackctl explicitly requests no autostart when trying
to become a jack client.
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options JackNoStartServer) || getenv(JACK_NO_START_SERVER)) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
jackd fork/exec stuff
presence of process with jackdbus auto' commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
--
Nedko Arnaudov GnuPG KeyID: DE1716B0
pgpfxCboeFzWw.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
Fons Adriaensen f...@kokkinizita.net writes: On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote: The configuration file is stored in ~/.config/jack/conf.xml (location conforming to the XDG Base Directory Specification). Frankly I don't give a damn for that spec, or in fact anything from that self-styled group of *** who have apparently never in their lives seen a computer without a running desktop, have no idea of how things are done on a Unix-like system, are the source of all misery I've been confronted with lately, and are slowly turning Linux into something worse than Windows (I mean freedesktop.org). To start with, jackd is not a desktop app, and Unix/Linux apps are traditionally configured using an ~/***rc file. To be honest I dont care about the location of the file. It is fine with me and I'm not going to advocate XDG, it is a fight between you and them. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpHmP1YLVQUg.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes:
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options JackNoStartServer) || getenv(JACK_NO_START_SERVER)) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
jackd fork/exec stuff
I can read this and it can mean different things.
- This code is not involved in what happens
- The value of the options argument is wrong.
It is involved in what happenes. At least from what I've got about the
problem you have.
You have installed jack package that does not work well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus. But you havent configured it. QJackCtl is dbus
ignorant. You should not use qjackctl with jackdbus system. Unless you
know what you are doing. Or unless qjackctl gets jackdbus support.
jackdrc style commandline options for jackd are for jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
presence of process with jackdbus auto' commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
I know that. The fact remains that when the 'jackdus auto'
daemon is running a jackd is started whenever qjackctl is
started. You can go on to deny this, but that doesn't
change the facts.
So you complain about qjackctl missing support for jackdbus? Having that
will be nice :)
--
Nedko Arnaudov GnuPG KeyID: DE1716B0
pgpgHZy0sPwCp.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] What are we talking about.
Stéphane Letz l...@grame.fr writes: Packagers are then strongly recommended to prepare the classic or the D-Bus JACK2. Dependancies have to be handled accordingly (Nedko please clarify this point...) The mixed target should *not be used* for packaging. (see http://trac.jackaudio.org/wiki/JackDbusPackaging) We have suggested packaging approach: http://trac.jackaudio.org/wiki/SuggestedPackagingApproach We can fix something if someone thinks it is not good. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgps9PhxqsdEa.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote: You have installed jack package that does not work well with qjackctl (dbus enabled one). Your application autostarted jack server through dbus. It did not. No jack app here uses dbus. If i got it right (dbus enabled libjack.so) then every jack app on your machine uses dbus. jackdrc style commandline options for jackd are for jackd. They are not used for jackdbus. They cant be used for jackdbus. Because of the object activation works in all distributed object systems I know. This includes DCOM and D-Bus. What nonsense it this ? Everybody here tells me that the dbus support is build on top of the existing C API and nothing else, that it just a communication layer allowing you to access the C API. Hence jackd is the same with dbus or without. Or isn't this true, and is the dbus support much more invasive than some people want to admit ? I dont get what you are talking about. Please explain. The client that autostarted a jackd did not use dbus. When I later started qjackctl it did not use dbus. libjack.so will not start jackd if compiled in dbus. Actually it can but only if jack server start through dbus failed. Obvisouly it didnt because you said that it got started with wrong arguments, right? Yet the 'jackdbus auto' daemon (which nobody needed since all apps use the C API, but started anyway) interferes with clients not using dbus at all. again if you have jackdbus enabled libjack.so all your clients DO interact with dbus. Are you trying to say that on a jack+dbus system *all* jack apps have to be dbus-aware (or fail) ? NO. dbus knowledge is behind libjack. But yes, they load libdbus.so when they are started. Maybe you want to verify that with ldd? So you complain about qjackctl missing support for jackdbus? Having that will be nice :) Is that supposed to be funny ? Yes :) Final remark: the dbus advocates here are seriously contradicting themselves. 1. Dbus is just a communication layer. no it is distributed object model. this somewhat bigger than IPC. 2. Dbus adds functionality that can't be provided via the normal interfaces. and no again It can be added. You can reinvent the wheel. You can reuse other already invented mechanism. D-Bus was choosen because it is already quite widespread in Linux systems. Both can't be true at the same time. they are both false but even if they were true they can be both true, according to my understanding of logic :D if A and B are not corelated then A and B can be true at the same time. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpZ3Al58oyuR.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Rui Nuno Capela rn...@rncbc.org writes: So you complain about qjackctl missing support for jackdbus? Having that will be nice :) from where i stand, qjackctl does not need jackdbus support whatsoever. it's kind of the other way around, if i may say. and the way around is not about qjackctl per se, but to plain old good command-line jackd. In jackdbus system qjackctl is unusable for starting and configuring the jack server (there is no jackd executable). However qjackctl can still be used to monitor xruns and DSP load and as a patchbay application. fwiw, qjackctl just runs the jackd server as documented and interfaces to libjack through its plain client api. it has been doing this for years and rightly so, imo. Yup I know that. And this is why it works as patchbay and monitor app when used with jackdbus. however, by having jackdbus in the picture and when everybody would think it would be the holy grail, it is breaking all that instead just because it wants to rule the game on its own. it's doing it with complete disregard to what long time qjackctl/jackd users have been thought. that's disgraceful to say the least. It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't show messages generated by jackd when jackd is autolaunched by regular jack client application? Last time I checked those messages go to application's stdout (that is inherited from the parent process - the one of the normal jack client application). The issue that started this holy war is that dbus enabled package that contains also jackd got into the hands of Fons and ate his babies. The problem is already fixed in svn. qjackctl will not work when dbus is enabled unless both jackdbus and jackd are compiled and installed and after the packager ignores the warning text at configure time. qjackctl will not work because there will be not jackd executable installed. i strongly believe that all this trouble is a matter or something that just has been overlooked on the jackdbus development, that is, a misinterpretation, a bug that can be squashed right away once it's perfectly identified. Unless you point to what is wrong nobody who knows how jackdbus system operates will understand what you mean. however, if all that is due on a jackdbus design decision instead, then i am sorry, i'll digress. a completely new qjackctl has to be written from the ground up. just don't ask me to do it, at least anytime soon :) I asked you to add support for jackdbus (there are qt dbus wrappers) more than a year ago. It was in December 2007 IIRC. Not that I hoped a lot even back then. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpPb2FmvcEBJ.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Paul Davis p...@linuxaudiosystems.com writes: On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela rn...@rncbc.org wrote: from where i stand, qjackctl does not need jackdbus support whatsoever. it's kind of the other way around, if i may say. and the way around is not about qjackctl per se, but to plain old good command-line jackd. i'd like to clarify (again) based on ongoing conversations in #jack. the issue that qjackctl could consider is not jackdbus, or dbus in general. its the JACK control API that was discussed at LAC 2008. right now, qjackctl simply claims to know how to start the JACK server, offers a dialog to let the user pick settings, and then constructs a set of command line arguments for jackd. this will continue to work forever, but it is less flexible than we would like (consider what happens every time JACK gets a new option added (or taken away). the control API allows a control application to query the jack server (actually, its really querying the library that contains the implementation of the jack server that the control app is linked with), and discover what the available parameters are etc. etc. the dbus stuff is really mostly orthogonal to this (i stress the mostly) - its just another example of a control app/system. there's no reason why qjackctl would or should want to interact with it. however, the one area where these things overlap is auto-start. this is because what it means to auto-start a JACK server differs in the following two scenarios: * vanilla JACK install - there is no jack control system in place or in use * with jackdbus - there is a daemon in place listening for requests to start/stop/reconfigure the server in the first scenario, the ~/.jackdrc file (if it exists) takes care of auto-start. but if jackdbus is in use, then auto-start means something really quite different. we are are discussing ways to reconcile these differences on IRC. for those who don't understand why the second scenario is worth considering, i would point to the questions that (relatively) frequently come from users about changing a running JACK system to use another h/w interface, or to start/stop JACK temporarily for some reason. there is one school of opinion that would say that stop jackd and restart it with the correct parameters is the correct approach to this question. i think that at LAC2008 it was felt that we could do better. I confirm this it true (except about LAC2008 because i was not there and i dont know). And i want to add that qjackctl can be made more flexible if it can detect jackdbus. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgppeQ0Q0FWOQ.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Jamin's multiband EQ as LV2 plugin ?
James Warden warj...@yahoo.com writes: I was toying with the following idea: take jamin's graphical multiband EQ and reshape it into an LV2 plugin. Is this a redundant idea in case someone else is already working on something similar ? Just let me know before I start looking into this. Do you plan to build custom LV2 GUI too? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpftcxr9chbC.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] zynjacku-4
In this release: * lv2rack does no longer require PHAT (it was not really using it even in zynjacku-3 release) * Support for out of process plugin UIs (the upcomming nekobee release should use it) * Don't crash when trying to load non-existing plugin (specified by supplying plugin URI at commandline) * Don't crash with some plugins (NULL extension_data) zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK MIDI input port (routed to all hosted synths) and one (two for stereo synths) JACK audio output port per plugin. Such design provides multi-timbral sound by running several synth plugins. zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid parts for synthesis itself and you have flexible part that allows synthesis to suit your needs. lv2rack is a host for LV2 effect plugins. You need slv2 library to compile zynjacku tarball. Project homepage with screenshots: http://home.gna.org/zynjacku/ Get tarball from here: https://gna.org/files/?group=zynjacku -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp2O2r9EeEku.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] lv2dynparam1-2
lv2dynparam is LV2 extension for dynamic parameters. The extension consists of a header describing the extension interface and libraries, one for plugins and one for hosts, to expose functionality in more usable, from programmer point of view, interface. Changes since version 1: * host library: API is refactored, the new API is NOT compatible with the version 1 API * host library: support for dynparam automation * host library: support for dynparam parameter save/restore Project homepage: http://home.gna.org/lv2dynparam/ Get tarball from here: https://gna.org/files/?group=lv2dynparam -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp9wOdOyvUuq.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] zynjacku-3
In this release: * Plugin presets (save/restore) * Improved support for Calf plugins (various extensions needed by development version) * MIDI CC/Pitchwheel automation. Not yet available for custom UIs. Works for float parameters only. * Replace PHAT fansliders with bundled knobs. PyPhat is no longer required. * lv2dynparam host library is now optional. To enable support for dynparam plugins (lv2zynadd) lv2dynparam1 version 2 is needed. zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK MIDI input port (routed to all hosted synths) and one (two for stereo synths) JACK audio output port per plugin. Such design provides multi-timbral sound by running several synth plugins. zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid parts for synthesis itself and you have flexible part that allows synthesis to suit your needs. lv2rack is a host for LV2 effect plugins. You need slv2 library to compile zynjacku tarball. Project homepage with screenshots: http://home.gna.org/zynjacku/ Get tarball from here: https://gna.org/files/?group=zynjacku -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpAqL2CFDBTh.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] JACK for openSUSE 11.0 x86_64
oc2...@arcor.de writes: and even jack2 is providing this scheme: http://trac.jackaudio.org/wiki/SuggestedPackagingApproach I've changed the page and it now contains this paragraph: All different releases of JACK should be considered internally incompatible - that is, it should never be considered possible to mix versions of the JACK server with other versions of the JACK library/ies, drivers or internal clients. Packaging should ensure that no packages associated with different releases of JACK are ever installed simultaneously. Especially, having two versions of libjack.so installed simultaneously, often causes JACK programs using one libjack version not being able to operate with JACK server of other version. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpyXvxvxdBdF.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] MIDI and audio patchbays
Julien Claassen [EMAIL PROTECTED] writes: Hello folks! One question, I hope it's not too dumb. :-( If you have your average patchbay, how does it know, when new MIDI/audio ports/clients come to live or die? And how does it know, that some connection was killed by some other application. Does it simply query it all the time? I wouldn't think so... But perhaps I'm wrong... Both full refersh and notifications are possible. Notification mechanism is still lacking port renamed functionality. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp48QEZuRppO.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lash-0.6.0 release candidate 2
alex stone [EMAIL PROTECTED] writes: BTW I'm surprised that you managed to connect Rosegarden trough a2jmidid. I was under impression that it needs static alsa-jack bridges, I may not have explained this properly. In the pic you can see RG midi cabled to LS midi. Both are Alsa. I couldn't use the a2jbridge. lpatchage cannot patch ALSA. Thus I really dont how you did that :] This indeed sounds strange. Maybe it is some bug in jackdbus patchbay code. As test, can you please check whether those audio connections appear through libjack interface, either using qjackctl or jack_lsp with -c option? Qjackctl confirms the ports are cabled together. They simply don't show as connected in lpatchage, even with a refresh, or restart. Can you please create simple test case for reproducing the issue? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpvy1Ukq4Va0.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lash-0.6.0 release candidate 2
alex stone [EMAIL PROTECTED] writes: I have, in the lpatchage window, lash active, and a2jmidi active reflecting the successful run state. Not sure what else to include here. There's no hard crashing going on, or odd behaviour so far. (And i'm pleased Ingen is running ok now, on F8, CCRMA, 32bit. The 64bit boot is stable, with jackdbus, etc, but you know that already, as you helped me 'tune' it, a little while ago. Thanks) I've been out of the loop for a while, but there's a sizable 'coming together' of all these components, and it shows. I'll post more if i have a problem, or challenge, as i use it more. Alex, thank you for your report! Having everything works smoothly is very encouraging! The only major LADI thing that I've not implemented yet is support for liblash-less clients. Main target is ardour :) I hope to fix this before the end of November. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpdK61EsOSjP.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lash-0.6.0 release candidate 2
alex stone [EMAIL PROTECTED] writes: Nedko, if you're lost in this then i have no chance. :) With everything still intact, and the visible cable connections still active in the lpatchage pic i posted before, this is what qjackctl shows me. http://shup.com/Shup/80256/jack1.png This shows you have JACK MIDI connections between rosegarden and linuxsampler. both apps are alsa seq and midi goes: rosegarden - a2jmidid - jack midi - a2jmidid - linuxsampler qjackctl shows jack midi connections in midi tab, alsa seq connections in alsa tab. http://shup.com/Shup/80256/jack.png does not open here And here's the lpatchage pic of RG, my midi keyboard, and LS, all lashed together, reflecting the connections shown in Qjackctl. http://shup.com/Shup/80261/patch3.png Those are JACK MIDI connections. This tells me i have connections in both alsa, and a2j, at the same time. If lpatchage shows me a connection(s) then what is it? a2j? You've already written that lpatchage can't patch alsa, so it must be a2j, yes? yes ;) I will admit here i don't understand how i can connect RG in lpatchage, if RG is static bridge and won't respond to a2j. The pics seem to say otherwise, and the connection to Linuxsampler as well has me thoroughly mystified, if this is the case. (And i'll be the first to admit i'm a complete wizard at the gentle art of user error.) RG is not static bridge. I was refering to alsaseq-jackmidi static bridges. a2jmidid is dynamic bridge, dynamic means, it automatically creates JACK MIDI ports for ALSA seq midi ports. I've tried to exmpain things in a2jmidid README: http://home.gna.org/a2jmidid/README My confusion about RG is, that I was under impression that rosegarden does not create output alsa seq midi ports but just sends midi events to exisiting alsa seq midi input ports. I think i've checked this but maybe I just got it wrong. I dont really use RG. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp3DzV9b6rpR.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] lash-0.6.0 release candidate 2
release candidate 2 has some important fixes: * Fix for #46 - on first save of newly appeared clients, their state was not correcttly recorded as being saved and thus was not being restored on project load afterwards. * Memory corruption fixes caused by bug in stdout/stderr handling code. Was happening when lash client outputs lot of data to stdout or stderr * Improved handling of repeating lines sent to stdout/stderr I would like to ask LASH beleivers and other interested parties to test the 0.6.0 release candidate. Juuso Alasuutari and me have been doing some major changes to the lash code. We have done lot of work, we've fixed several big implementation issues and we need stable point before doing more changes (0.6.1 and 1.0 milestones). In the tarball there is simple lash_control script. One can also control LASH through patchage-0.4.2 and through lpatchage (availabe through git). User visible changes since 0.5.4: * Use jack D-Bus interface instead of libjack, enabled by default, can be disabled. Ticket #1 * Allow controlling LASH through D-Bus. Ticket #2 * Use D-Bus autolaunching instead of old mechanism. Ticket #3 * Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4 * Client stdout/stderr are logged to lash.log, when clients are launched by LASH daemon (project restore). Ticket #5 * Improved handling of misbehaved clients. Ticket #45 * Projects now can have comment and notes associated. Ticket #13 Download: http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2 http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2.sig -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp9BKrOplL4M.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] zynjacku/lv2rack development update
* zynjacku is updated to latest state of lv2 art * lv2rack - a lv2 effect rack (jack) is created (reuses lot of zynjacku code). * zynjacku development moved to git: http://repo.or.cz/w/zynjacku.git Testers welcome ;) For lv2 midi event port synths (the new ones), you will need slv2 svn r1698 (at least) Short term plans: * Cooperate with Krzysztof Foltman on calfwidgets+lv2rack/zynjacku * Ubuntu packages for lv2zynadd, zynjacku and lv2rack * Listen to feedback :D -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpC2jlXCkFbC.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LASH - some questions comments
Thanks for your comments Bob! Bob Ham [EMAIL PROTECTED] writes: On Thu, 2008-10-16 at 00:10 +0200, Fons Adriaensen wrote: 2. lash_extract_args() The type of main()'s argv is char *argv[], so why is the second argument a triple pointer ? Re-arranging the elements of argv does not require access to the variable argv itself, only to its elements, and for this a double pointer is all you need. I think the better option would have been to use environment variables rather than command-line arguments. That would have required no fiddling at all. As for why a double pointer was used, it was likely because I was following the method used in GTK+ et al. I also think that LASH should use environment and remove use of arguments for LASH business competely. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpFhTQm4czbG.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] DIY Trigger - Piezo to MIDI to PC
Ray Rashif [EMAIL PROTECTED] writes: And regarding MIDI, if I want to take into consideration dynamics, and let the piezo trigger MIDI messages with varying attack information, how would it be done? So depending on the voltage generated, it'd be a MIDI-ON but the final message to the computer (audio interface) would be a MIDI-ON ATTACK == 75 sort of logic. Sorry for the noobish description, have just started to dabble into (audio/midi) electronics. I know a way to implement this. I've read it somewhere in Internet. piezo output is limited using zener diode (you want to do this anyway because next electronic components may get burned out). Then you can measure width of the impuse. Wider the impulse is, more attack you have. In midi terms drum attack becomes midi note on velocity parameter. I understand the concept and design roughly and I can move on by reading the construction manual (refering to edrum's DIY guide), but at the moment I'm looking for a quick way to build a trigger as I need it asap (and no $$ for a real trigger kit/module). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpaYycTdWo8K.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LASH - some questions comments
Emanuel Rumpf [EMAIL PROTECTED] writes: Hi Hello Emanuel I get handler/signal doesn't exist messages. If I press the save button in lash_panel: lash_control_signal_handler: Received unknown signal 'ProjectSaved' lash_control_signal_handler: Received unknown signal 'ProjectModifiedStatusChanged' Is that expected behavior ? (lash 6.0rc1, Compiled with JACK 0.109.2, D-Bus 1.2.1, libxml2 2.6.32, ALSA 1.0.16 ) $ lash_save_button lash_control_signal_handler: Received unknown signal 'ProjectModifiedStatusChanged' Add client (New Project): c93429bd-c532-4482-b33b-d156ff53c8a7 method_default_handler: Method SaveProject with signature on interface org.nongnu.LASH.Server doesn't exist I haven't really tested liblash control API after dbus changes. I think it is safe to assume that it is deprecated. Thus, please test with patchage or lpatchage instead of lash_panel and lash_save_button. Juuso and Dave, do you think we should remove these control apps from make install? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgprqFQ58WljF.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Lash-dev] Re: LASH - some questions comments
schoappied [EMAIL PROTECTED] writes: There is posted a message for testers here: http://linuxmusicians.com/viewtopic.php?f=24t=622 and a discussion about lash here: http://linuxmusicians.com/viewtopic.php?f=28t=609 If you need testers in the future maybe good to left a message there or/ and on the LAU mailinglist? Thank you for your forum post about rc1. Posting announce of rc1 to dev-only lists only was intetional. The reason is to avoid user frustration that can be caused by unpolished software. Also devs are supposed to be able to give better feedback for crashing software. If everything goes as I expect, rc2 announce will probably be posted in laa and lau mailing lists too. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp0ZOcF3wF0H.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] lash-0.6.0 release candidate 1
I would like to ask LASH beleivers and other interested parties to test the first release candidate for 0.6.0. Juuso Alasuutari and me have been doing some major changes to the lash code. We have done lot of work, we've fixed several big implementation issues and we need stable point before doing more changes (0.6.1 and 1.0 milestones). In the tarball there is simple lash_control script. One can also control LASH through patchage-0.4.2 and through lpatchage (availabe through git). User visible changes since 0.5.4: * Use jack D-Bus interface instead of libjack, enabled by default, can be disabled. Ticket #1 * Allow controlling LASH through D-Bus. Ticket #2 * Use D-Bus autolaunching instead of old mechanism. Ticket #3 * Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4 * Client stdout/stderr are logged to lash.log, when clients are launched by LASH daemon (project restore). Ticket #5 * Improved handling of misbehaved clients. Ticket #45 * Projects now can have comment and notes associated. Ticket #13 Download: http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc1.tar.bz2 http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc1.tar.bz2.sig -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpuGudo5NQGm.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Chris Williams [EMAIL PROTECTED] writes: Paul Davis wrote: The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. [snip] LV2 seeks to solve this via the extension mechanism. This is one of the areas I'm really not happy about, especially the current (admittedly tentative) extension mandating not only a gui toolkit (gtk), but also the idea that the plugin should implement the Widget interface while the host should already be running the gtk main loop. Ouch. The problem with the extensibility argument is that no host is going to implement it fully, properly or consistently (as mentioned, it's hard enough for this to happen with a tightly-defined, compact spec) which leaves client developers still not knowing what they are dealing with. DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. AFAIK it is perfectly possible to implement LV2 UI extension that handles GUIs in DSSI way, i.e. through OSC. This is probably the best approach if plugin author wants single custom GUI that works for most hosts. The fact that only GTK variant is defined, is caused by the fact that all currently involved parties tend to like GTK and use it in their hosts/plugins. I'm one of them, but I like generated UI's more, one of the reasons I've started dynparam extension work some time ago. So, if one wants custom GUI, options are: * Write one GUI per toolkit * Write single out-of-process GUI and route it through OSC, DSSI-like, or some other IPC mechanism. * Use low level X protocol, if possible at all - see Fons Adriaensen's followup mail. If you want single GUI that could work in any host, the additional option is generating it through some UI description mechanism, with dynparams extension being one that I use. As a side note, I think Lars Luthman made some time ago a research into hosting QT plugins in GTK host or vice versa, but I'm not sure what the result was. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp4jziPtKu5J.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] a2jmidid version 4 Devsirme released
a2jmidid is a project that aims to ease usage of legacy ALSA sequencer applications, in a JACK MIDI enabled system. a2jmidid implementation is based on jack-alsamidi-0.5 that is [almost] same as jackd ALSA seq MIDI backend, both created by Dmitry Baikov. Static bridges are based on code by Sean Bolton and Lars Luthman. Homepage with screenshots: http://home.gna.org/a2jmidid/ Tarball download: http://download.gna.org/a2jmidid/ Changes since version 3: * Fix typos in docs * Disable use of C++ demangling in sigsegv. Fix for sr #2074 * Fix a2j_control help text (thanks kfoltman!) * Request fixed JACK client name. Fix for bug #12139 * Handle missing svnversion executable nicely. Fixes bug #12138 Changes since version 2: * Improved port naming, support for bidirectional ports * Allow exporting of hardware ports (disabled by default) * Switch from autotools to waf * Remove support for old JACK MIDI API variants * Remove usage of posix semaphores that could cause sleep in realtime context, in rare circumstances * D-Bus background service mode. The old manual mode is still working. * Log file when running in background service mode. * Improved documentation * Import, with slight modifications, static bridges created by Sean Bolton and Lars Luthman. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpR9wVXuNpxi.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [ANN] a2jmidid version 3 Bodrum released
a2jmidid is a project that aims to ease usage of legacy ALSA sequencer applications, in a JACK MIDI enabled system. a2jmidid implementation is based on jack-alsamidi-0.5 that is [almost] same as jackd ALSA seq MIDI backend, both created by Dmitry Baikov. Static bridges are based on code by Sean Bolton and Lars Luthman. Homepage with screenshots: http://home.gna.org/a2jmidid/ Tarball download: http://download.gna.org/a2jmidid/ Changes since version 2: * Improved port naming, support for bidirectional ports * Allow exporting of hardware ports (disabled by default) * Switch from autotools to waf * Remove support for old JACK MIDI API variants * Remove usage of posix semaphores that could cause sleep in realtime context, in rare circumstances * D-Bus background service mode. The old manual mode is still working. * Log file when running in background service mode. * Improved documentation * Import, with slight modifications, static bridges created by Sean Bolton and Lars Luthman. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpOvXsb4lQQr.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Writing a library?
Julien Claassen [EMAIL PROTECTED] writes: Hi! Yes the autotools are good. cmake might be better, but it is not as well known and often used as autotools and scons. As I heard scons should be enough for a lot of things. Even for multi platform stuff. Csound uses it and seems fine with it and a couple more linux (multiplatform) applications like ardour. my choice would always be between autoconf/automake/et al. and scons. For both learning is necessary. For scons it's python and for the autotools it's the macro-language. Both seems to have nice reference docs... I'd sugeest you waf, takes goods sides of autotools (separate configure stage), scons (python) and cmake (nice progress indication). And even has good features that are unique. Like. waf being part of source tree, thus multiple developers cannot end with having different versions of the build tool. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpXmrgodW6UA.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] latency issues (practical aid needed on a practical example) (fwd)
Julien Claassen [EMAIL PROTECTED] writes: Hi everyone! (this was first posted on Linux-Audio-Users, but is probably really more suited to this list.) I just compiled a sound generator, which can be controlled vai MIDI, it uses simpe raw-midi and jack as output, via bio2jack. Now I have horrible latency 0.2-0.5sec (rough estimate). Where should I start looking in my setupt. I know others had the software running without problems. Sorry for being so abstract, but I'm not allowed to mention the software. :-( I already tried setting internal audio-buffer to 128 samples and reducing message queues for the tonegenerator and MIDI. Still it's much too much latency. Does bio2jack have some settings for reducing latency? Does bio2jack do samplerate conversion, is it costly? The sound-engines samplerate is set to 44100 or 22050 and my JACKd runs at 48000. But I could post parts of the source if necessary. My setup is: Debian Lenny with custom built kernel 2.6.24-rt1 JACK subversion 0.109.0 jack-commandline: jackd --timeout 4500 -R -d alsa -d hw:1 -r 48000 -p 128 -H -M -z shaped ALSA version 1.0.15 Any idea where to optimise? Kindest regards Julien Realtime addicted people tend to use JACK with realtime kernel and JACK MIDI ;) No bio2jack eresy :P -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpWKmvWkmQUn.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] More proposed LV2 addition/extension stuff
Krzysztof Foltman [EMAIL PROTECTED] writes: Steve Harris wrote: You're right, we never defined the lv2:binary predicate. While you're adding stuff to lv2core, you might as well consider adding some of those (+/- any discussions that arise and probably rewrite in proper English), or perhaps I should move some of them into separate extension(s): :trigger a :PortProperty ; rdfs:label Trigger ; rdfs:comment Indicates that the data item should be considered a Boolean value corresponding to the specific event that was detected (control output ports) or is to be triggered (control input ports). For input ports, the port needs to be reset to false by the host (any value less or equal than 0) after run() function is called. . (Boolean? discrete? based on if :integer or :toggle is present? a feature that says :trigger that is supported? use special labeled events instead?) :supportsStrictBounds a :Feature rdfs:label Supports strict bounds ; rdfs:comment Indicates use of host support for :hasStrictBounds port property. A plugin that specifies it as optional feature can omit value clamping for :hasStrictBounds ports, if the feature is supported by the host. When specified as required feature, it indicates that the plugin does not do any clamping for input ports that have a :hasStrictBounds property. . :hasStrictBounds a :PortProperty ; rdfs:label Has strict bounds ; rdfs:comment For hosts supporting the :supportsStrictBounds, it indicates that the value of the port should never exceed port's minimum and maximum control points. For input ports, it moves the responsibility for limiting the range of values to host, if it supports :supportsStrictBounds. For output ports, it indicates that values within specified range are to be expected, and breaking that should be considered by the host as error in plugin implementation. . These probably belong somewhere else, but I'll post them anyway: :expensive a :PortProperty ; rdfs:label Changes trigger expensive calculation ; rdfs:comment Input ports only. Indicates that any changes to the port value may trigger expensive background calculation (eg. regenerate some lookup tables in background thread). Any value changes may have not have immediate effect at all, or may cause silence or diminished-quality version of the output data to be produced until background processing is finished. Ports having that property are typically not well suited for connection to outputs of other plugins, and should not be offered as connection targets or for automation by default. . :causesArtifacts a :PortProperty ; rdfs:label May cause audio artifacts when changed ; rdfs:comment Input ports only. Indicates that any changes to the port value may produce slight artifacts to produced audio signals (zipper noise and other results of signal discontinuities). Connecting ports of this type to continuous signals is not recommended, and when presenting a list of automation targets, those ports may be marked as artifact-producing. . :continuousCV a :PortProperty ; rdfs:label Carries a smooth modulation signal ; rdfs:comment Indicates that the port carries a smooth modulation signal. Control input ports of this type are well-suited for being connected to sources of smooth signals (knobs with smoothing, modulation rate oscillators, output ports with continuousCV type etc). Typically, a plugin with this type of ports will implement appropriate smoothing to avoid audio artifacts. . :discreteCV a :PortProperty ; rdfs:label Carries a discrete modulation signal ; rdfs:comment Indicates that the port carries a discrete modulation signal. Input ports of this type are well-suited for being connected to sources of discrete signals (switches, buttons, classifiers, event detectors etc.). May be combined with :trigger property. . Having these things defined (either as part of core or as extension(s)) would be very useful. Hosts rendering generic UIs like zynjacku will use them for sure. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpTX7KYPAlfI.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Let's kill EPAMP???
Stefano D'Angelo [EMAIL PROTECTED] writes: #3. Some serious connection logic thing (all the equal channels thing etc.). This needs a thousand flame wars and *deep* thinking. No idea what you mean by this. If someone is going to write that helper library (or adjust SLV2 or whatever), I guess we should find some reasonable conventions to organize and use plugins in a chain-like thing. This is damn hard, as Paul Davis outlined already on this mailing list, and I actually don't know to which degree it should be done. Looks like good cadidate for separate helper library. But as Paul said, proably each player will end with its own helper library. Example: some LV2 extension tells the host that which parameter is a quality vs. speed parameter in a plugin. The host can, then, show a global quality vs. speed parameter to the user. In dynparam extension there are hints for this. They could be used as generic UI generation hints, as MIDI mapping hints or as quality vs. speed hint. I think this could be done for normal LV2 ports too, i.e. assigning hint URIs with a port. #7. Global explicit initialization/finalization functions for more exotic platforms (they wouldn't harm, so why not having them). I still dont get what is the use case for this. Both on the host side and on the plugin side, no need for #ifdefs to define initialization/finalization functions and maybe support for exotic platforms not having them. I dont see what you will do within those global initialization/finalization functions. That thing needs to be something not platform specific. This can be made as separate thing that can be reused for other things too. The same way libtool is asbtraction to shared libraries. #8. Rules to find plugins possibly platform-specific and outside of the specification; possibly one compile-time valid path. AFAIK, this conficts with LV2 spirit. Why one needs this? If the goal is to avoid RDF Turtle, this shouldnt be issue with proper helper library for hosts. Still such feature could be implemented in such a helper library. Nope. I mean there should be platform-specific rules to get the list of directories containing shared object files and possibly there should be a fixed path to check on each platform, known at compile time. Interface to SLV2 (-like) library should definitively allow modification of directory list. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpTRkXb9nYzk.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Let's kill EPAMP???
Stefano D'Angelo [EMAIL PROTECTED] writes: #7. Global explicit initialization/finalization functions for more exotic platforms (they wouldn't harm, so why not having them). I still dont get what is the use case for this. Both on the host side and on the plugin side, no need for #ifdefs to define initialization/finalization functions and maybe support for exotic platforms not having them. I dont see what you will do within those global initialization/finalization functions. That thing needs to be something not platform specific. Well, I for example would use them with NASPRO to fill the plugin with all effect descriptors (don't know yet how to do with RDF/Turtle, but I'll find a way). This can be made as separate thing that can be reused for other things too. The same way libtool is asbtraction to shared libraries. ? You need absatraction for defining global constructor/destructor in shared library. As Larsl already said, you can use some C++ tricks (like constructor of global object), for this. In my vision, such thing is bound to creation of shared library file, this is why I mentioned libtool. #8. Rules to find plugins possibly platform-specific and outside of the specification; possibly one compile-time valid path. AFAIK, this conficts with LV2 spirit. Why one needs this? If the goal is to avoid RDF Turtle, this shouldnt be issue with proper helper library for hosts. Still such feature could be implemented in such a helper library. Nope. I mean there should be platform-specific rules to get the list of directories containing shared object files and possibly there should be a fixed path to check on each platform, known at compile time. Interface to SLV2 (-like) library should definitively allow modification of directory list. Which kind of modification? * get list of lv2 plugins (extracted from LV2_PATH by slv2) * modify that list (add/remove directories) * (maybe) get path of directory where plugin resides -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpTjjDQURm4i.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
