[LAD] Sorting LAC Recordings
Hi! So I finally managed to name and sort the conference recordings. http://lad.linuxaudio.org/events/2007_tub/ Except: http://lad.linuxaudio.org/events/2007_tub/some_concert_1.theora.ogg http://lad.linuxaudio.org/events/2007_tub/some_concert_2.theora.ogg where I don't know from which day/event they are. In http://lad.linuxaudio.org/events/2007_tub/23_friday/ the concer-ambisonics*, is that the tesla concert? As there already are some tesla concert files (maybe I labeled those incorrectly?) http://lad.linuxaudio.org/events/2007_tub/24_saturday/paul_davis__audio_on_linux_no_sound.theora.ogg Is sadly without sound, it would be nice if someone could combine it with the audio file. Also, if somone is willing to cut a bit: http://lad.linuxaudio.org/events/2007_tub/25_sunday/sunday_track_1.ogg Seems to contain the whole day, even though there are 3 other files. The name already indicates the problem: http://lad.linuxaudio.org/events/2007_tub/25_sunday/jaya_kumar__olpc_audio_subsystem__pieter_palmers__firewire_2.ogg And the poor Rui is cut into 6 pieces in http://lad.linuxaudio.org/events/2007_tub/22_thursday/ LAC now moving around makes me wonder if the programms and papers should be collected on lad.linuxaudio.org (or event.linuxaudio.org), too. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] Widgets
Hi! I have been working on concepts and mockups on knobs, radial popup menus and sliders. http://thorwil.wordpress.com/tag/widgets/ Feedback and implementations welcome ;) -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] Phat and pyphat 0.4.1, help needed for future widgets.
On Tue, May 08, 2007 at 11:57:27PM +1000, Loki Davison wrote: > > what? ... cairo can render svg. http://en.wikipedia.org/wiki/Svg > What i was hoping for was a means of rendering the svg's drawn by > thorwil http://thorwil.wordpress.com/ > > So a graphics designer creates the svg file to render and the code > just does what ever realtime modifications are required to show the > actions, I.e change how much of the indicator is filled it and the > rotation of the knob, etc. > > Dynamic drawing? NOt sure if i get you, as i you have to recompile to > get changes? Loki, there are inaccuricies in the files as Inkscape isn't exactly a precision tool. Plus you need to rotate some parts and either move fills or do some masking. So I think the use of drawing operations is the way to go. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] LV2 beta3
On Wed, May 09, 2007 at 12:44:22PM -0400, Thomas Vecchione wrote: > > While this makes perfect since in flexibility from a programmer > perspective, I wonder how it will affect things from an end-user > perspective, especially if LV2 becomes popular(Which many hope it would)... > > The end user will have some plugins that are 'LV2' that will work in > some 'LV2' hosts but not others. How are they to know? Will they have > to have 'LV2 and supports these features' that they will have to check > off every time to see if it should be working or not? > > Or 'Profiles' that fit a certain set of features? Hosts will be able to not ever list plugins they can't use, afaik. I think it's likely that something one could call profiles will crystallize, as plugins are made for more or less specific uses. Many effect plugins make sense both in a DAW and a synth, but sound generators like oscillators tend to not make sense in a DAW. Synth plugins need hosts that deal with MIDI (well, perhaps OSC). I mean there will be sets of needs that apply to plugins and hosts. In the worst case we will need a table of what works where :) -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] LV2 beta3
On Wed, May 09, 2007 at 07:14:05PM -0400, Thomas Vecchione wrote: > >Either way, everything just works (or not) as it should. > > > > Not to someone not familiar with the internals of how LV2 works. As an > example(I hate to bring up) how many people do you think could tell you > how the ineternals of a VST program work. Heck how many do you think > have an even basic idea of computer programming, much less tell you the > above. What has understanding internals to do with this? All that will need to be understood is that is-an-LV2 is not enough to describe a plugin or host. > Again for a programmer and specifically someone familiar with how LV2 > works, that is fine. For someone that has no concept of programming, > and just want something that works when(To them) it is supposed to, this > is a huge screwup that can be fixed relatively easily to be honest. Fixed relatively easy how? > Once again, this is not about me I am mentioning this. This is for the > half dozen people(As of right now, obviously not counting those that I > have gotten used to linux and how things work that might start again) > that still come to me wondering why something doesn't 'just work'. Do you propose to not have a plugin standard that can be extended for various current and possible future needs to avoid some possible user confusion? Shall all hosts be forced to support all extensions available so that a sample editor would have to "support" MIDI plugins? -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] LV2 beta3
On Thu, May 10, 2007 at 08:51:22AM -0400, Thomas Vecchione wrote: > > And how is it doing to be described is my point. At the moment it is > being described as a function of what internal extensions are there in > the case of something that does beyond the spec. If this was one or two > extensions it wouldn't be bad at all, but since we are aiming for > expandability BEYOND what we can thing of right now I think it is a > large mistake to not plan for what would happen if there are 50 > different extensions. How about waiting a bit what extensions appear at all? Can't make meaningful plans for profiles or whatever beforehand, anyway. > Again no. A host could still choose whatever they support. However, > for example, an audio host might support the audio extensions, a video > host might support the video extensions, and a host that is midi capable > the midi extensions. If you are dealing with 20 or 30 extensions there > for whatever reason, are you honestly going to have an end-user go > through and say, ok this extension is present, this one is present, this > one is not, crap my plugin won't work or will be missing a gui. For the common user, hosts and plugin collections should be part of the distribution he uses. Ideally host packages would recommend plugin collections, but I only know that feature from Debian. Anyway, the issue of the user having to check what works where doesn't has to appear in this case. It might be far easier to list the supporting hosts for each plugin, once the number of extensions outgrows the number of hosts. It's not difficult to read a plain list. > Do not get me wrong, as I have said repeatedly thus far, LV2 is nice and > highly expandable, and I certainly don't want to change that, but that > by itself will not make it usable for the end user. Power and > flexibility do not necessarily equate ease of use, and personally I do > not see a reason why this could not have all three, it is close as it is > and the only thing holding it back are clear definitions of what will > and won't work where for an end user that doesn't require 20 minutes > worth of work for each plugin to see if it SHOULD work. This has much > less to do with the technical requirements of the spec, and much more to > do with looking down the road and realizing that if this spec IS fully > taken advantage of, things might very well get messy. Please recognise that a new standard needs a phase of experimentation. You simply can't decide on every possible what-if and nail everything down, as then nothing is ever pushed out the door. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] LV2 beta3
On Thu, May 10, 2007 at 12:53:44PM +0200, [EMAIL PROTECTED] wrote: > > the problem will be rather: why has this plugin a GUI in ardour and > ingen and not in qtractor. > > while this other plugin has a gui in qtractor and non in ardour and > ingen. So how can the toolkit issue be adressed? Could there be something like GUI hosts to assist plugin hosts by running plugin GUIs that use another toolkit? What does DSSI do? -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] [ANN] LV2 beta3
On Thu, May 10, 2007 at 10:11:19AM -0400, Thomas Vecchione wrote: > >For the common user, hosts and plugin collections should be part > >of the distribution he uses. > > > Oh I sincerely hope we are not going to tie people in like this, that > would be a VERY bad thing IMO. Tie in? > What happens when arbitrary extensions are made by a handful of people, > for a handful of plugins on a year by year basis. In a couple of years > you have significantly more than a handful of extensions. This is FLOSS, right? Nobody gets to tell people what to do or not in the end. So if anyone wants to create 'arbitrary' extensions, he will. No profiles, no nothing change that. It's a wild software jungle out there anyway and I really do think we have to rely on distributors to make it more handable for the average user, where average user refers to everyone who is for whatever reason not able or inclined to go out there to explore, test and learn. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] new lossless/lossy audio compressor
On Wed, Jul 25, 2007 at 12:47:16PM -0700, Gregory Alan Hildstrom wrote: > ... or suggest another untested codec ... http://www.true-audio.com/ http://www.musepack.net/ http://www.speex.org/ http://www.wavpack.com/ I'm most interested in the last. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] new lossless/lossy audio compressor
On Thu, Jul 26, 2007 at 07:04:18AM +1000, Erik de Castro Lopo wrote: > > - Do you have any thoughts/plans on adding metadata like song title, > artist, copyright info etc? Besides using an existing container format, there are the metadata standards id3, APE and Vorbis Comment. http://www.id3.org/ http://en.wikipedia.org/w/index.php?title=APE_tag&oldid=127659489 http://en.wikipedia.org/w/index.php?title=Vorbis_comment&oldid=119930411 > - Have you thought of putting your codec data inside other standard > container formats like WAV, Caf and Ogg? Or Matroska. Ogg and Matroska are not (yet?) supported by libsndfile, though. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] new lossless/lossy audio compressor
On Thu, Jul 26, 2007 at 10:59:33AM +0800, Victor Roetman wrote: > Openoffice's .odt files and Microsoft's .docx files are merely zip > containers with directory structure and files inside. You could just do > something like that, and it would be very easy to take apart again. It > would also not be impossible to modify some program like rhythmbox to > read those files directly. Of course, maybe easier said than done. More and more complete support for Matroska would be preferable to yet another approach. It seems to be more than flexible enough. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] new lossless/lossy audio compressor
On Wed, Jul 25, 2007 at 04:19:03PM -0400, Paul Winkler wrote: > Pretty cool. Does JPEG 2000 handle float data? > > I'd love to be able to write an archive script for Ardour sessions > that compresses the audio data losslessly, but FLAC won't do it. WavPack does it. http://www.wavpack.com/ -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] LV2 " isn't well thought out ?" LV2 in the Reaper sequencer
On Tue, 2008-01-22 at 15:18 +0100, Benno Senoner wrote: > I think the attitude of certain LAD-ers is one of the reasons why > linux audio will > remain an irrelevant niche for a long time to come. How about you put in names, coward? You imply that there is some kind of overall linux audio thing. You also seem to imply that it staying an irrelevant niche is a bad thing. If you want to benefit from someones work offered for no charge, you might have to at least tolerate their different point of view. > How can you you create a standard like LV2 and then make statements > like > "reaper is the enemy" ? Who called it an enemy? Even then, what has one to do with the other? Why shouldn't one make a standard to suit ones own need and not care about what groups with different views do ro don't do with it? > I think LV2 devs did not do their math correctly, since it seems that > every non GPLed app > is labeled as the enemy, they should change the LV2 license to GPL and > it will > avoid pollution by proprietary apps. Utter bullshit. Members of the LS project shouldn't give lixensing advice, anyway. > So LV2 devs, what was the true reason to release LV2 under LGPL ? > (which allows the API > being used by proprietary apps too) No one said they can't use it. Stop making up statements that weren't given. > Pieter summed it up well, LV2 devs should speak out whether they want > to create > a true standard or an open-source application standard only. > But given their attitude regardless of LGPL or GPL I don't see a great > future for LV2, > it will probably be used by a few open source niche apps and it was > about it. Please wake up to the fact that even if you just look at the core team, Steve and Dave, you already see different views. You deal with individuals. Scary, I know. If you want to see LV2 make it beyond "a few open source niche apps", do something for it. Just because you might think it's a good goal doesn't mean others have to. > But it seems that people here simply don't care, what counts is one's > religious belief. Different > religions are not accepted. You still fail to differentiate between individuals. You deride other peoples values/priorities as religion, only because you don't share them. Then you complain about non-acceptance, but that's exactly what you do: you don't accept differing values/priorities. > If the need arises, other groups will be formed and they will put into > practice their ideas. Talk is cheap. > If we were such close minded like certain LADers here LS would not > enjoy this kind of success. > Politeness, openess and dialogue is the key. Is this mail an example of your politeness and openness? I think I have to throw up! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LV2 "isn't well thought out ?" LV2 in the Reaper sequencer
On Tue, 2008-01-22 at 12:25 -0500, Darren Landrum wrote: > I thought we were all on the same side? There might be tendencies, but it's not one side. > * Ardour looks, behaves, and has almost the exact same feature set as it > did two years ago. (Nobody in the commercial world is still using a > 32-bit mixing engine, not even Pro-Tools.) You haven't looked closely enough. What's wrong with 32 bit floating point or Ardour's "mixing engine"? > You can go ahead and tell me to leave if I don't like it, but the truth > is, I like the spirit of the Free Software world, and if I feel I can > contribute something worthwhile, then I will. It's just too bad that we > can't seem to work together on some issues. Some do work together on some issues. Not everyone's pulling in the same direction. Never will. > I came to here from Reaper, hoping to have seen the whole idea of audio > production on Linux advance. And it has, to a point, but now you're at a > crossroads: Do you want an elite club, or do you want to see the world > of Linux audio spread far and wide? There's no single we, not even one road. > If Justin doesn't want to implement LV2 in Reaper, that's his choice. No one claimed different. > So the > choice becomes, do you want LV2 to stay elite, or do you want an > industry standard? Industry standard? Call it that if Steinberg and Apple adopt it ;) > Open source doesn't do anybody any good if nobody wants to use it. See, it's rather that some don't want to use anything else. > As for me, my interest is in DSP and coding plug-ins. I got started > playing around in Reaper's Jesusonic. Now I want to grow my skills in a > useful direction. Is that going to be LV2, or VST3? I wish I knew. Think about who you would want to be able to use your plugins under which circumstances. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LV2 " isn't well thought out ?" LV2 in the Reaper sequencer
On Thu, 2008-01-24 at 21:15 +0100, Esben Stien wrote: > "alex stone" <[EMAIL PROTECTED]> writes: > > > we just want to avoid somebody to directly make money with our work, > > that is by selling our software in a sampler product like a sampler > > + sample library bundle, a hardware sampler or something equivalent, > > at least not without giving something back to the open source > > Community." I don't quite see what would stop a company from bundling LS with commercial content, stating that LS is included as a freebie. > But that's really the funny thing here. Your software isn't from the > free/open source software communities. It doesn't conform to neither > the free software definition nor the open source definition. The really funny thing would be the authors going MIA and nobody being there to give that permission that at least commercial distros might think is required. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] JACK Synthesizer Manager Proposal
Hi! Audun Halland and I have been thinking about a set of related problems. The first result is the following proposal, meant to gather feedback from the community. I'm posting about this to both LAD and LAU, but separately. Hopefully we can keep it technical here and have the user POV on LAU :) Please feel encouraged to come up with additional use cases and implementation ideas. You can read the following with a little bit of markup on http://thorwil.wordpress.com/2008/01/26/jack-synthesizer-manager-proposal/ or the same text right here: JSM, the JACK Synthesizer Manager We propose a programm that acts as a proxy between sequencing software and both software and hardware sythesizers. Among the goals are unified patch selection and making projects more portable. If we get the impression that the JSM is something that both developers and users will find handy and use, then development might start real soon. In this text, we avoid going into technical details to foster free thought and discussion. Use Cases 1. Patch selection Goal: Choose patches from all available hardware and software synthesizers. Giorgio uses a single means to select a patch among all patches of all of his software and hardware synthesizers. He uses meta-data to find the right patch. The right connections are made automatically. 2. Computer as syntheszier Goal: Use the computer as a compound synthesizer in a live performance. Hiromi has her keyboard connected to her laptop live on stage. She uses several soft-synths via keyboard-split and layering. A few selected parameters are bound to the wheels of the keyboard. After each song, she switches from one setup to the next with least effort. 3. Collaboration Goal: Exchange projects without having to change settings back and forth. Alice and Bob take turns on working on a project. They use different hardware but don't have to manually change connections and choose patches on each turn because of an abstraction layer. MIDI Interface Ports The problem with MIDI interface ports is that the hardware on the other side and its setup might change. Or be entirely different if people exchange projects. An abstraction layer can make this more comfortable to handle. The JSM takes care of the mapping between software ports and MIDI interface ports. It can work on a per MIDI channel level. Patches and Instrument Definitions Patches and controllers are chosen by name; the user doesn't have to deal with cryptic numbers. For kit-programms, name mappings are given (e.g. bass drum on C1). Patch selection happens by a single means, offering all available patches (JACK apps, plugins, hardware). Making the required MIDI and audio connections is automated as far as possible. Categorization Categories help to find the right patch among many. When exchanging projects, they help to replace unavailable patches with similar ones. Virtual/Compound Synthesizers >From the outside, the computer can be dealt with like a single compound synthesizer. Different synthesizers can be triggered from ranges on a single keyboard (key splits). Synthesizers can be layered. The whole setup can be switched with programm changes. JACK to ALSA Bridge JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack "SYSTEM" midi ports, the jack world only sees the devices offered by JSM. -- Audun Halland and Thorsten Wilms ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] JACK Synthesizer Manager Proposal
On Sat, 2008-01-26 at 19:16 +0100, Dennis Schulmeister wrote: > Just a litte question to better understand your idea. How would a > sequencer request a certain patch on a certain channel on a certain > port? I think the patch selection would be more part of the JSM than the sequencer, but the details must be figured out in collaboration with sequencer authors. So it wouldn't be the sequencer requesting a patch, but rather patch selection throughy the JSM, the JSM providing all necessary info to the sequencer and changing connections. > With plain MIDI the sequencer would just send the appropriate control > change / program change values on the given channel and midi port. > Without knowing which device would interpret the values in which way. > > How would that be different with an abstraction layer? How could an > abstraction layer assure that a given PC/CC value pair would always > refer to a certain kind of patch? Regardless of the system and > synthesizer setup employed. > Obviously there would be some kind of translation. But who would define > the translation rules? Who would define what kind of patches JSM can > handle and which not. The JSM developers might come up with a "snappy > synth bass". All a user would have to do was to tell JSM how to select a > "snappy synth bass" patch on a given synthesizer. > But they might not come up with a "blurry sound from space which sounds > like a cat screaming when its tail gets clamped by the door". The user > wouldn't be able to reliably select such a patch. Simply because it > wouldn't be offered to him. On the other hand he could extend the > translation rules to offer such a patch. But than again it wouldn't work > on a foreign setup. The minimum the abstraction layer would do, is automatic switching between profiles. One per environment. This way you would not have to adapt everything on each iteration of working on a project in turns. Patch selections could be stacked. One selection for each environment. The next thing could be virtual ports to represent roles in the project. Roles like drum-module or lead-synth. Then replacing unavailable patches with patches that are similar as far as that can be discerned from meta-data. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] LinuxSampler and GPL - some clarifications
On Sun, 2008-01-27 at 01:02 +0100, Mlf Conv wrote: > This means that: > 1. usage of a computer program licensed under the terms of GPL in a > hardware product, whether modified or not, is not a distribution of a > computer program licensed under the terms of GPL, and is thus > prohibited by GPL. I don't follow on this one. I was under the impression that it's perfectly ok to include GPL software in hardware, but that the sources must be provided. > 2. usage of a computer program licensed under the terms of GPL, > whether modified or not, in a software product, the intention of which > is not to distribute a computer program licensed under the terms of > GPL, is not a distribution of a computer program licensed under the > terms of GPL, and is thus prohibited by GPL. Huh? > So to summarize that with respect to LinuxSampler, the exception > "LinuxSampler is licensed under the GNU GPL with the exception that > USAGE of the source code, libraries and applications FOR COMMERCIAL > HARDWARE OR SOFTWARE PRODUCTS IS NOT ALLOWED" is in fact no exception > at all, and is already covered by GPL. We have been told that the LS team talked to the FSF people. If things would be so easy, I'm sure it would have been resolved already. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 2
On Sun, 2008-01-27 at 12:33 +0200, Nedko Arnaudov wrote: > > * User interface standard recommendation (documentation). > > fit: -5 > > I dont think this is in the scope of LASH. > IMHO, such plans fit much more to PHAT project. I think such a standard would just start with what labels to use for LASH related actions and how to organise menu items. It could contain one or the other layout recommendation or how to handle certain scenarios regarding notifications and dialogs. So all things with a clear relation to LASH. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] JACK Synthesizer Manager Proposal
On Sun, 2008-01-27 at 12:55 +0100, Dennis Schulmeister wrote: > > The idea is to provide the JSM with a patch and synth (and other > > metadata) database, > > and a mechanism for sequencers to connect to and query the database. So > > patch selection > > will happen in the sequencer in the classical sense: > > I think that contradicts to what Thorsten wrote: It can always be that we have somewhat different ideas, especially at this early stage. > > I think the patch selection would be more part of the JSM than the > > sequencer, but the details must be figured out in collaboration with > > sequencer authors. So it wouldn't be the sequencer requesting a patch, > > but rather patch selection through the JSM, the JSM providing all > > necessary info to the sequencer and changing connections. > Thorsten also writes about JSM providing info to the sequencer. But as I > understand it the trick is that the sequencer tells JSM what sound it > wants so that JSM can find and select an appropriate patch from one of > the available synthesizers. I wanted to emphasise that all the "knowledge" should be in the JSM and that a sequencer as client only offers an interface to use the JSM. As such, a sequencer would never request a patch from the JSM that needs to be resolved, because patch selection already happened through the JSM so the selected patch is clearly defined. > That's how I understand it: JSM implements a standard patch list. Much > like the General MIDI patch list (only more comprehensive). When JSM > receives a patch change it makes use of the user provided synth profile > in order find a synthesizer and to select a fitting patch from it. The General MIDI standard patch list will be useful thanks to all the hardware supporting it and it could make sense to allow specifying GM equivalents for Patches to have a fallback. But the general idea is not a standard patch list, but listing everything that is available in the specific environment plus having meta-data for filtering/searching. Unifying patch selection is at the core, improving the portability of projects comes second. Instead of having to select a device (implicitly via a port/channel), a bank and a program number, the user should be able to pick a patch from a flat list, aided by searching/filtering. Comparable to what Ardour does for plugin selection (as pioneered in Om/Ingen). It is not desired that only a description of the patch is stored and resolved each time; the patch selection ends with a specific patch. However, it might be possible to store search terms with the selection and use them once the project is opened in another environment. Thanks for your thoughts! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] LinuxSampler and GPL - some clarifications
On Sun, 2008-01-27 at 14:37 +0100, Marek wrote: > > > On Jan 27, 2008 1:19 PM, Luis Garrido > <[EMAIL PROTECTED]> wrote: > > 1. usage of a computer program licensed under the terms of > GPL in a hardware > > product, whether modified or not, is not a distribution of a > computer > > program licensed under the terms of GPL, and is thus > prohibited by GPL. > > > I don't follow you there. Why the exception you mention > (selling > computers with Linux preinstalled) is indeed a exception and > not the > rule? > > It's the only case i can think of right now, that allows to > distribute GPLed software inside hardware for profit, > because you're making profit out of the hardware not the software. The Tivo, several routers and other appliances ... -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] vector drawing software
On Thu, 2008-08-07 at 14:03 -0400, nescivi wrote: > At first sight it seems more geared to 3D modelling for animation graphics, > rather than for making realworld objects. > I need to model some things in order to "print" them on a rapid prototyping > machine... > Is Blender a suitable candidate for that? AFAIK rapid prototyping machines work with triangle meshes, so using a polygon modeler is no problem. It's even the way to go for organic shapes like action figures. There's a RP startup that works with Blender a lot. However, for precise geometrical shapes, Blender is the wrong tool. It can be done to some degree, but it is just painful compared to a decent CAD tool. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] vector drawing software
On Thu, 2008-08-07 at 20:17 -0400, nescivi wrote: > Do you know any decent open source CAD tools? > I haven't yet found one I am completely content with Nope. There's http://brlcad.org/, which looks like much-is-possible, but-everything-is-damn-hard. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] linuxaudio.org
On Sat, 2008-10-25 at 11:40 +0200, Robin Gareus wrote: > Ivica Ico Bukvic wrote : "We need to start thinking about the function > of the management board. This aspect has been all but dead. How about we > announce restructuring of the board and go from there? My suggestion is > to retain the core of those of us who are most active and then add key > figures in the community who will be active contributors to our cause." > > No surprise there. Further discussion may or may not follow on > http://lists.linuxaudio.org/listinfo/consortium/ - and last but not least: Seems that belongs on the consortium list and shouldn't be on LAD and LAU!? > * http://wiki.linuxaudio.org > open to public (openID/CAPTCHA) > > Everybody is welcome to use this wiki for gnu/Linux and FLOSS audio > related projects or communication. Feel free to ask for additional > permissions or plugins. - send your project application or suggestions > to LAD, start writing a wiki page about it or send a patch ;) Nice. > We would like to support maintained and moderated namespaces adopted by > members of the community; balancing http://linuxaudio.org/members in > favor of interest groups. We have neither intentions nor budget to take > on wiki.ubuntu.com or wikipedia. Commercial interest is tolerated. > Professional interest in linux-audio is more or less a prerequisite. The > usual exceptions apply for Music, Art, etc. see http://linuxaudio.org/policy I'm not sure what you are talking about here and highly suspect others will be even more puzzled. Balancing? Regarding namespaces (nice example of coder speak not suitable for a general audience), I see it as a problem that linuxaudio.org web presence is so fractured already. > ..and we're not going to stop there. > > Here's a quick overview of HTTP services, vhosts and tasks. Any comments > and suggestions are appreciated; as is help getting there: > > * http://lad.linuxaudio.org - will be consolidated into drupal > (www.linuxaudio.org) and wiki.linuxaudio.org. - Apart from the > http://lad.linuxaudio.org/events/ (lots of pictures and media) there's > only 16 HTML pages. - similarly lowlatency.linuxaudio.org should become > an entry-point to the wiki. > > * http://lad.linuxaudio.org/events/ should be merged with > http://lac.linuxaudio.org Consider conference.linuxaudio.org or conf.linuxaudio.org. Redundant redundancy department / cryptic abbrev. ;) > * http://portal.linuxaudio.org, http://linuxaudio.org, > http://lac.linuxaudio.org/ > Drupal CMS is edited and maintained by the consortium. I actually think portal shouldn't exist. Should be just a list of links reachable from linuxaudio.org . Like it is, but the link name "Portal" doesn't cut it. Maybe "Ressources"? > We're urgently looking for 2-5 Content Maintainers (and Guitarists) so > that some of us can take a holiday break. I suspect writing a long and partly confusing email while assuming everyone already knows what this is all about and what you want to accomplish is not the best way to invite contributors. > Besides in the longer term we're looking for volunteers to summarize or > comment on a LAD/LAU thread once in a while, and editors to write short > articles in the likes of kerneltrap.org. > > > * http://wiki.linuxaudio.org/ is actually the same as > http://apps.linuxaudio.org/wiki/ - vhosts will be merged, redirect.. One of the URLs will be dropped? Which one? I though one is an open wiki for content that is not necessarily tied to single applications and the other a directory of linux audio applications? > * http://lau.linuxaudio.org and http://quicktoots.linuxaudio.org/ > probably remain as is. There are a lot of hidden resources there! - > Maybe some minor updates on the front-page. point to the wiki or portal. Ah yes, the fragmentation. _Hidden_ resources are great for Indiana Jones style explorers, I guess? ;) I would rather drop old material to have a chance of introducing something structured, where a newcomer would know where to start and had a chance of finding stuff without using a pit lamp. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] 1 and 2 and 3 and 4 ...
Hi! This already went to the LAU list, please ignore if you are subscribed there, too. This is a call for contributions. Take your chance of becoming part of a crowd of people all around the world, counting to the rhythm in several languages! Contributors will be credited in order of their submissions and this will also likely influence the order of use in the track ;) Besides recording yourself and family and friends and pets (if they are able to count), you can help by spreading the word. What I'm after are recordings of one person at a time, saying: A: "One Two Three Four" B: "One and Two and Three and Four and" C: "Beat" (to be translated to whatever makes sense 4 times in one measure at 4/4. A single utterance is enough, as I want to use these as accent.) - Translated in a native language and any language spoken without much of an accent. If there are special ways of counting to the beat in a language, use those (only or even better additionally) and inform me. - With a tempo of 110 beats per minute (to be very clear, the "and" has to be between beats ;). - A and B should ideally be recorded with about 4 iterations (4 measures) Don't think that your language will already be well-represented without you. Others might think the same ;) Also, the more I can layer in one language, the better. All files should be: - ideally wavpacked, or plain WAV as second choice - 32 bit float, 48 KHz - Trimmed - Normalized - Dry - Explicitly licensed as http://creativecommons.org/licenses/by-sa/2.0/ or released to the Public Domain _Only_ if you don't record with a JACK application, 16 and 24 bit integer formats are also acceptable. Please name the files as follows: - firstname_lastname_language_count.wav for "One Two Three Four" - firstname_lastname_language_count_and.wav for "One and Two ..." - firstname_lastname_language_beat.wav for "Beat" Email attachments are no option for such large files, so only send links to uploads. Consider using http://www.getdropbox.com/ if you have no other space. Please mail me off-list for submissions and on-list for questions. I'm also available as thorwil in #lad and #ardour at irc.freenode.net. My intention is to offer the result and the material on archive.org. This is an open-source project ;) I also want to submit a version to the https://wiki.ubuntu.com/UbuntuFreeCultureShowcase I can't promise to use all contributions. I will sort out ones that sound suspiciously different from others claimed to be in the same language ;) However, all serious contributors will be given credit. Deadline: I will start to work with the material as soon as I have enough, but will accept more until the 23rd of January. Thanks! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] uli-plugins 0.1 release - A series of LV2 plugins
On Sat, 2009-07-04 at 22:20 +0200, Ulrich Lorenz Schlüter wrote: > Thorsten Wilms schrieb: > > ./waf configure failed to find lv2-plugin. I had to comment/uncomment > > lines in wscript to make it look for lv2core instead ... so you seem to > > know about this problem in principle? ;) > > > > But now I get: > > ../gates/and2i.cpp:1:25: error: lv2plugin.hpp: No such file or directory > on my Gentoo the lib lv2-plugin comes with a package named > lv2-c++-tools. The missing header also belongs to that package. > Everything should be fine after installing. Oops, installed lv2-c++-tools, undid my edit and now it builds. Thanks! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] uli-plugins 0.1, duplication
On Fri, 2009-07-03 at 23:19 +0200, Ulrich Lorenz Schlüter wrote: > The release contains a simple series of logic gates. Namely an AND, > NAND, OR, NOR, XOR, XNOR and a NOT. > http://uli-plugins.sourceforge.net So now I looked through the plugin menu in Ingen to check for the duplication I suspected: AND, NOT, OR and XOR are also present in Krzysztof Foltman's Calf plugins (if configured with "--enable-experimental". I didn't test any of these, but I guess there's not much room for malfunction or differing behavior, right? ;) It would be great if you guys could get together to make sure there's only one implementation of these very basic things, preferably in a convenient package. This will make it easier to share lv2-using modular-synth patches or sequencer sessions/arrangements. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Background on the Impro-Visor project
On Mon, 2009-07-27 at 19:10 +0200, Ralf Mardorf wrote: > Hi Bob :) > > Robert Keller wrote: > > However, I don't feel that I > > am obligated to accept every suggestion that someone makes about > > software that is my own. > > You used GPL stuff without accepting the GPL? Less people understand the > GPL completely, but c'mon you're an academic. Maybe you are obligated by > ethics to share your own software with other people who make it possible > for you by their own, but libre and open sourced software or even people > that never did anything for you. That's not at all what he said. Ralf: seeing your obvious problems with (English) reading comprehension - not for the first time - I must say the best you could do is to keep out of this. > > I have contacted sourceForge > > about his posting of sources relating to the project, and they > > suggested filing a copyright infringement (the project is copyright by > > me and Harvey Mudd College). Mr. Keller: Either the code is GPL and redistribution is allowed, or it isn't GPL and therefore would break the GPL license of another project, if I got that part of this thread right. > You don't want that Raymond does forge his own version of Impro-Visor? > Why not? I can't see any damage by doing this. Possible reasons: - duplication/waste of effort - making things harder for users and distributors, having to look into the differences and implications - emotional attachment due to long and hard work - not wanting to see credit given to the forker standing on _his_ shoulders Those who don't write and release code should be very careful when discussing such issue with those who do. > > a lot of the thinking that went into the project is > > that of me and my students. > > > > And also by some GPL coders. > > You won't share your knowledge? Another thing that wasn't said / doesn't follow. Cut it out, please. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Background on the Impro-Visor project
On Mon, 2009-07-27 at 13:34 -0400, lase...@gmail.com wrote: > Size of GPL code included is irrelevant. True. > Inappropriate expectations. No license file was included in distribution, > no text to indicate GPL. GPL violation #1. Yes, but I'm willing to believe it was negligence. > These are excuses. Not buying it. A bunch of rubbish. Assuming > your users are dumb is very impolite. Assuming that your users would have trouble dealing with source code is very different from assuming they are dumb. > You don't have to accept every suggestion. That is fine. But my suggestions > which were actually real code were better than what you were doing. So the > refusal was quite illogical. My code was GPL, so no problem there. The > suggestions I made will make there way into the fork, then others will > wonder what the heck was Bob thinking to refuse these practical bug > fixes. Maybe it's true, but you do sound very arrogant and pushy to me ;) > Again, irrelevant. Excuses, excuses. All over the place. Stick to > the license, then there is no problem. Sure. But it sounds like it was an honest mistake. Even if it wasn't your aggressive tone doesn't help at all. > This contains some lies. The first message I received from Bob had > an insulting tone to it, as if I was doing something wrong by asking for the > source. Nice attempt at back-paddling. Rubbish, throughout. We all know how clear-cut tone in emails is ;p What is anyone supposed to do with lots of hearsay, anyway? > If you want respect, give respect. Stop assuming you are somehow in a better > position. It is very condescending. I see a 50% chance you should apply those lines to yourself. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Background on the Impro-Visor project
On Mon, 2009-07-27 at 14:36 -0400, lase...@gmail.com wrote: > > Assuming that your users would have trouble dealing with source code is > > very different from assuming they are dumb. > > No, it is always condescending. Anybody can go to SF and download. It > is not brain surgery. There would be more involved than just the download, and even that alone can be an issue for naive users. Have you ever been involved with and user testing, or just observed casual computer users? > > Maybe it's true, but you do sound very arrogant and pushy to me ;) > > Too bad. I have an attitude because I am not going to let people push > me around and insult me for being right. If you cannot comprehend > that from all the posts then perhaps you should keep your ideas to > yourself. You haven't had to deal with this person. One person's lack of manners is another person's attitude, I guess. > Where do all these people come from that assume style equals substance? > What you are really perceiving is backbone. Maybe you are not familiar > with that. I don't know where those people would come from. I didn't say there's a lack of substance. Aggression tends to cloud rationality and hinders amicable solutions. > I see 100% chance that you do not know what you are talking about because > you are not closely involved. You should check all the posts more carefully. > Don't worry you will not be the first person who does not see this clearly. You must be the one single person who knows what is going on and what is right and wrong in this case. What's this thread for? I mean, you have your fork, right? You already judged the other side. You don't take or need any input, it seems. You clearly stated your position. Anything left? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Tue, 2009-07-28 at 02:28 -0700, Robert Keller wrote: > There are copyright and GPL notices in every non-trivial source file. > Do I have to add another separate file as well? You should include the text of the GPL in a file usually called COPYING. See http://www.gnu.org/licenses/gpl-howto.html -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Wed, 2009-07-29 at 08:08 -0400, lase...@gmail.com wrote: > On Wednesday 29 July 2009 04:21:08 you wrote: "you wrote"? I can't understand how you could ever look into a mirror with good conscience while having your mail user agent configured in such a way as to use a "you" instead of a name. This makes you a liar with each message to a mailing list! This is an OUTRAGEOUS VIOLATION of the most basic logic and also manners! STOP VIOLATING this mailing list. BTW, for the rest your are just wrong and Chris is right. You really need to wake up and start to think! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] students and copyright
On Sun, 2009-08-02 at 13:31 +0200, Ralf Mardorf wrote: > Referring to the copyleft statements by Stallman and the FSF you can > have a copyright by FLOSS, by GNU, but not by the GPL itself. The > institute might have a copyright for the software's name and the logos, > but each coder has to copyleft his changes on GPL code. I have no idea what you mean with copyright "by FLOSS, by GNU, by GPL". On a name or logo would be trademark, not copyright. > Students or developers for proprietary companies that don't use GPL code > might lost the copyright for their intellectual property because of > contracts. What ever I have done for Brauner microphones when I worked > for him, is owned by Brauner and not by me. I was paid to do it, even if > I was disproportional bad paid. Students won't get money, but the > universities might have contracts with the students, resp. with > proprietary companies that cooperate with universities, so they might > have to pay less college tuitions. > > For the GPL there only seems to be one way. The coder needs to keep the > original author and to add his name and the date when he changed GPL > code and if he writes complete new code, he needs to add his name and > need it to do by matching to GPL versions of GPL code done by other > authors, that is included to his project. No institute can take on a > copyright, while the institute is using GPL licensed code. > > I don't understand the GPL, but this is repeated and repeated by > Stallman and the FSF. I don't think, that I'm mistaken, but I might be > wrong. I don't see how that would work out. It's up to the copyright holder to license the software as GPL. AFAIK, you can give away your copyright on your works in some jurisdictions, including the US. That means you can sell it or give it away and there can be clauses to that extent in contracts. This might be more complicated in countries such as Germany, where citizens are not legally able to give up their copyright. But I guess you can still grant someone else all rights, irrevocably, just not exclusively. Copyleft/GPL build on copyright. It's the lever to do anything. Of course you have to keep all names of people that didn't hand over copyright to you in. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] FLTK vs GTKmm
On Mon, 2009-08-10 at 08:38 +0200, Christian wrote: > I'm just curious what your long-time experiences with these > gui-libraries are. > Considering to use one of these two but can't really decide. > But I do not want to switch in a year or two... Well, I can't say anything about developing with either one of them, but I think you should also take into account how the result will look and feel. All examples of FLTK I know of look horribly out of place on a modern desktop. Like, the 80ies want their GUIs back! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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?
On Sun, 2009-11-08 at 14:39 -0500, David Robillard wrote: > New idea: it is tempting to define a very simple turtle document format > for hosts to signify what they support, then this kind of compatibility > information could be automatically generated as well (and in a much more > useful form than a human could put together). The information is > already there for plugins. As far as I'm concerned the lack of > automatically generated documentation (and/or machine readable data in > general) is pretty much the sole reason for every single complaint > related to this whole thing. This way is also decentralized, but the > results for all "known" implementations could be hosted at lv2plug.in > (or anywhere else) for convenience. > > I am surprised I didn't think of this before, but it seems to be a > pretty good idea. All that is needed as far as maintenance goes is for > hosts to supply a simple turtle document that says "I implement foo and > bar and baz extensions". The rest can be compiled into whatever fancy > human readable form you want, for every single plugin out there, by a > tool. If I provide a template, would anyone be willing to put together > these documents? I will gladly write the tool if the data is there, and > the problem will be solved, and a convention set that solves it in the > future with basically no effort involved. As a start, I'll have a try with collecting a list of hosts and plugins and what features(/extensions) they provide or require right here on the list ;) Longterm it might be useful to have a way to query for this locally. For an application that builds a matrix for the hosts and plugins you have installed. Now, it's clear where to look for plugins, but some convention/mechanism would be needed to fin the host RDF files, right? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] List of LV2 hosts, plugins and features, add yours here
Hi! Plugin and host authors and those who happen to know this: please reply with at least 1 host or plugin(-set) and the provided or required features/extensions. I will then see that all that appears on the wiki. If Dave provides a template, I should be able to write the RDF files for the hosts. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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
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? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ @prefix doap: <http://usefulinc.com/ns/doap#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix hi: <http://lv2plug.in/ns/dev/host-info#> . <http://home.gna.org/zynjacku/software/ingen> a doap:Project, hi:Host ; doap:name "Zynjacku" ; doap:revision "5.0" ; doap:shortdesc "A host for LV2 Plugins." ; doap:homepage <http://home.gna.org/zynjacku/> ; doap:bug-database <https://gna.org/bugs/?group=zynjacku> ; doap:license <http://usefulinc.com/doap/licenses/gpl> ; doap:developer [ a foaf:Person ; foaf:name "Nedko Arnaudov" ; rdfs:seeAlso <http://nedko.arnaudov.name/foaf.rdf> ; foaf:mbox <mailto:ne...@arnaudov.name> ; foaf:mbox_sha1sum "0eec3ceb427be759748f6693a6663a0b" ; foaf:homepage <http://nedko.arnaudov.name/> ; ] ; doap:developer [ a foaf:Person ; foaf:name "Krzysztof Foltman" ; foaf:mbox <mailto:w...@foltman.com> ; foaf:mbox_sha1sum "335c21a4a6d1b0e8f0295fbf494bc89e" ; foaf:homepage <http://www.linkedin.com/in/kfoltman> ; ] ; doap:programming-language "C", "Python" ; doap:repository [ a doap:GitRepository ; doap:location <http://repo.or.cz/w/zynjacku.git> ] ; hi:supportsExtension [ hi:extension <http://lv2plug.in/ns/dev/contexts> ; ] , [ hi:extension <http://lv2plug.in/ns/dev/contexts#MessageContext> ; ] , [ hi:extension <http://naspro.atheme.org/rdf/old-dman#DynManifest> ; ] , [ hi:extension <http://lv2plug.in/ns/ext/event> ; ] , [ hi:extension <http://home.gna.org/lv2dynparam/v1> ; ] , [ hi:extension <http://home.gna.org/lv2dynparam/rtmempool/v1> ; ] , [ hi:extension <http://lv2plug.in/ns/ext/midi#MidiEvent> ; ] , [ hi:extension <http://ll-plugins.nongnu.org/lv2/ext/MidiPort> ; ] , [ hi:extension <http://lv2plug.in/ns/dev/progress> ; ] , [ hi:extension <http://lv2plug.in/ns/dev/string-port#StringTransfer> ; ] , [ hi:extension <http://lv2plug.in/ns/extensions/ui#external> ; ] , [ hi:extension <http://lv2plug.in/ns/extensions/ui#GtkUI> ; ] , [ hi:extension <http://lv2plug.in/ns/ext/uri-map> ; ] ; doap:description """ 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. """ . ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] planet LAD
On Wed, 2009-11-11 at 09:39 +0100, Arnold Krille wrote: > Would be cool to have a rss-feed to follow everything that is aggregated on > that planet. Well, there's http://planet.linuxaudio.org/atom.xml My feed reader found it for me, I don't see it on the page, though. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Mon, 2009-12-21 at 23:33 -0600, Gabriel M. Beddingfield wrote: > Also, with respect to saving and restoring sessions, > suppose this work-flow: > >1. Save a session (#1) with Ardour as a part of it. > Instead of transferring GB of data to the > session-data-dir, it stores a handle[1] to the > data (i.e. a URI tracing back to a save state). > >2. When session #1 is reloaded, Ardour loads the > handle to the original project's save state. > >3. User forces an export to the session-data-dir. > This means that Ardour must transfer all the > gigabytes of data necc. to recreate the session. > >4. User opens session #1 from an exported archive. > Ardour finds heavy data in the session-data-dir, > and uses it (rather than, say, importing the > data to some other location). > >5. User does a "save as" on the current session, > thus saving Session #2. Ardour saves a handle to > a save-state from Session #1 (and Session #1's > session-data-dir). > >6. User deletes Session #1. They now > have also corrupted Session #2. If you work with a session-managed Ardour, why not store audio files within the session-data-dir? Otherwise I see no reason _not_ to use the same exact Ardour session directories as now, keeping everything external and just needing one link to it. There is no "Save As" in Ardour. If there was, it would create a new session directory, including an "audiofiles" dir with hardlinks to the required audio files (symlinks if they are on another drive, though). No problem with deleting the other hardlinks, the symlink case remains ugly. I've long been thinking that the "handling heavy audio files" problem should be tackled together with the "using any media files within some kind of document or session" problem, combined with the linking-vs-embedding issue. Locally, you would never embed files, but always use handles of a kind that withstand renaming and moving of the files. Sending/transfering a document/session elsewhere would trigger bundling of all required files. Ideally, this would even include plugins. Think system-level dependency tracking and resolution. Well, seeing how difficult to impossible it is for people here to find consensus, I guess I shouldn't hope for LADers to team up with projects like Inkscape, Scribus and Lumiera :) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] aseqmm 0.2.0 released
On Tue, 2009-12-29 at 14:39 +0100, Pedro Lopez-Cabanillas wrote: > On Tuesday, December 29, 2009, Paul Davis wrote: > > i notice that SDLmm has not had a commit in nearly a year, and appears > > to have been named under a similar belief as your own. > > Is it about belief? There is something about that in the Universal > Declaration > of Human Rights. Article 18: "Everyone has the right to freedom of thought, > conscience and religion". I would also add the GUI toolkit and frameworks. > > Maybe you know the text of a Law, or a sacred text source of the absolute > truth, where it is stated that a library name ending in "mm" must not be used > by those not belonging to the congregation of true believers, under pain of > heresy ? I'm glad that we finally see someone fighting for humanistic ideals, for freedom of thought, speech and religion, truth and justice here, in the dark pits of ignorance and isolationism. You, Pedro, are a true champion of humankind! Expectations that follow from conventions are a lie, breaking them is true enlightened justice and who disagrees clearly doesn't like Qt for inhuman reasons. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Congratulations Ardour Team!!!
On Sun, 2010-01-03 at 12:27 +, Bob Ham wrote: > This "product", Mixbus, does indeed seem to be a modified version of > Ardour. However, I can't seem to find any source code or, for that > matter any downloads at all on the Harrison website. http://ardour.org/node/3011 -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] successive note on midi events
On Mon, 2010-04-12 at 08:07 +0200, Jens M Andreasen wrote: > The question is what happens at the other end when a note gets struck a > second time. > > a) Nothing, the note is already on. > b) Re-trigger, the voice is reset and the note gets played from the top > c) Trigger, a new voice is assigned and will play simultaneously to > previous voices a) and b) both might make sense for a monophonic synth part, but in the polyphonic case, it should be c). Doubling a note seems perfectly reasonable to me and accidental surplus Note-Ons are simply not acceptable (I'm also not aware of that being a common problem). -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] successive note on midi events
On Mon, 2010-04-12 at 12:30 +0200, Jens M Andreasen wrote: > Surprisingly, all classical polyphonic keyboards like piano and organ > works according to 'a'. If you - while playing four-handed piano - > accidentally strikes a note already held by the other player, nothing > will happen (in musical terms, that is ...) > > Polyphony is what is supposed to happen when you strike /different/ > notes and doubling notes will normally be done by pressing the > hold-pedal and then striking the note twice. There is no compulsory need to enforce the keyboard model unto the interpretation of MIDI. I don't think it should be part of a definition of polyphony, which to me simply is the simultaneous use of more than one voice, be that from a single or multiple instruments. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Mouse/knob interaction
On Sun, 2010-09-12 at 12:39 +0200, Olivier Guilyardi wrote: > In regard to phat, if only the SVG, or XCF, or whatever sources were on svn, > that would allow to tune the colors, the size, etc... Maybe that the solution > is > to redraw it in Inkscape. The source is a Blender file. Peter Shorthose took care of animation and post-processing after I did the design. I would think this has to be in a repo somewhere, but I have a local copy, anyway: http://dl.dropbox.com/u/485382/old_knob_3d.tar.bz2 Great how those won't die, as much as I wish they would, while all the stuff in http://thorwil.wordpress.com/?s=knobs didn't go anywhere. The main issue for me is that they always appear alien in GTK windows. Then the design is not strong enough to warrant creating a whole matching theme. They are not scalable. Creating such a series for a knob animation with Inkscape is not exactly trivial, if you want consistent lighting and a physical feel. For optimal, scalable results, the drawing should be coded, as otherwise you get issues with lines that should stay 1px wide and might be neighbors in some cases. With knobs, you still have a problem with putting them into a layout with labels. I think much could be gained with sliders with integrated labels: http://dl.dropbox.com/u/485382/sliders.png -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Mouse/knob interaction
On Mon, 2010-09-13 at 22:14 +0200, Olivier Guilyardi wrote: > For the default rendering of the blue part, using > GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a > color > (blue, brown, etc..) in many modern themes. However, in some other themes, > it's > just another shade of gray. > > Thorsten, did you think about this? Sure. AFAIR fan-sliders use that approach. I wonder if you can query for the color used for progress-bars. Either ignore unfortunate themes, or try to evaluate the provided colors, to use some fall-back if there isn't sufficient contrast. An option for user-defined colors would have the problem that users have to know about that and then have to bother defining it, if colors are unpleasant, otherwise. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Fwd: Re: [LAU] OpenOctaveMidi2 (OOM2) beta release
Alex, clearly mentioning the project you forked is just good manners of the kind that should be expected among civilized people. Your overreaction to Paul's mail is one hell of an ugly sight. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advice sought on project hosting and version control
On 02/12/2011 02:50 PM, Gordon JC Pearce wrote: Github seems to be pretty good. Just recently I wondered how Github and Gitorious compare. It seems Github is much more popular and is said to have more features. Unlike Github, Gitorious itself is Free Software. Github allows private repositories if you pay. It looks like it has more of a focus on individuals, while Gitorious puts more weight on teams. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] IR: LV2 Convolution Reverb
On 02/24/2011 12:43 PM, Fons Adriaensen wrote: It's also foolish to suggest that the 'all inclusive universal DAW' will cater for those needs - just ignore what you don't use etc. It most definitely does *not* because it's by no means as universal as you may think, but rather the reflection of one particular musical culture. Which means that whatever is not used in that particular scene will not be provided. Ardour, despite all it qualities and being a magnificent piece of work, is a good example of that. Now you talk about features not being provided, when the starting point was features that are provided. Also, 'ignoring the bits you don't need' is not always as simple as it may seem. The simple fact that these things _are_ provided has consequences on the overall design, they _do_ distract, they _have_ to be checked and disabled (often each time again), they _do_ take resources and they _do_ impact reliability. And they are not compile time options. Sure, a tool that offers exactly what you need and nothing more has something reassuring to it. But how much do you get to see of Ardour's MIDI support if you simply do not add any MIDI track to your session? > And for a professional user that is irrelevant. Spending some money on Protools is not really different to doing the same for a kilometer of microphone cable or some XLR plugs. You pay license fees for cables and plugs and you would never alter them in any way? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On 09/25/2011 05:07 PM, Aurélien Leblond wrote: No, they are designed for use within AMS - so some control ports > (those that should become connectors and not widgets) are at audio > rate. Ah pity, they would have been great with Ingen... There's nothing stopping you from using plugins with audio-rate control ports in Ingen. The reduced rate of ladspa and lv2 control ports is good for saving performance in cases where you don't need updates at full rate. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On 09/26/2011 03:37 PM, Aurélien Leblond wrote: Hi David, Could you let me know where in Omins it is? Well, not David, but: http://svn.drobilla.net/lad/trunk/omins/src/hz_voct_4200.c -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Conciderations of Design
On 11/11/2011 11:19 PM, harryhaa...@gmail.com wrote: I'm seeing downsides to each approach: 1: Tell it on every change -> performance hit 2: Request it every time it runs -> Keeping control over the many values & unique ID's of class instances This made me wonder what functional reactive programming * might have to offer here. This could be of interest: www.cse.chalmers.se/~dave/Courses/Topics/SavedProjects/2007/2007-reactive/report.ps * http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL?
On 11/16/2011 07:15 AM, Louigi Verona wrote: This is why I see any licenses that limit distribution and usage of creative work as undesirable and unfounded. Even things like GPL and CC seem to me like just lesser evil, as it still assumes that the author of the work can be considered an owner of his ideas and thus assumes that ideas can be property. This raises many-many problems, one of which is giving the author too much power over society. You may not like such licenses, even if I suspect you benefit from them quite much, but to call them unfounded is, and this is the nicest way to call it, ignorant. Especially the GPL has clear objectives and the widespread use is indicative of the need. Being based on Copyright, licenses like the GPL do not protect ideas, but at most specific implementations of ideas. If a programmer makes his source code available, that is a gift to "society". Doing so with restrictions attached can be seen to make the act less generous, but it is still on the giving side. It still is enabling, not limiting. To then talk about "power over society" is ridiculous. Don't like the conditions? Don't take it, no force applied, nothing taken from you! I see the GPL and similar licenses as a legal means of asking (and potentially forcing) people to play fair. If you build on top of someone else's source code, it's only fair to make the modifications available in the same manner. Give like you have received, an example of the golden rule. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL?
On 11/16/2011 09:53 AM, Louigi Verona wrote: The concept of property, made towards anything immaterial, makes little sense and is always found on some artificial unnecessary grounds, whereas property of physical objects is a concept based on necessary grounds - the scarcity of physical objects (and thus the need for individual control of those objects). The concept of property just is artificial in general. It wouldn't be "necessary" if humans wouldn't have this tendency to be selfish and greedy. As things are, the purpose is protection of investment of time and effort and scarce resources. Respecting property is part of an agreement to avoid chaos and war. Everything that can be expressed digitally is not scarce, once copied and distributed. But the know-how, time and effort required to producing it, is, and that's what's to be respected and protected. In a capitalistic society, it should be possible to earn money by investing your time and effort in producing things people need/want. People being paid for their time and effort directly may be preferable. There's still a need/use for copyright to protect the outcome, to allow the investment to be made beforehand. This way, payment can depend on the quality of the outcome. Oh, and in a funny twist, the GPL and similar licenses provide a reason for copyright on immaterial goods, as they have well founded objectives and copyright is the legal mechanism they rely on to be enforceable. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL?
On 11/16/2011 10:57 AM, Louigi Verona wrote: "In a capitalistic society, it should be possible to earn money by investing your time and effort in producing things people need/want. People being paid for their time and effort directly may be preferable. There's still a need/use for copyright to protect the outcome, to allow the investment to be made beforehand. This way, payment can depend on the quality of the outcome." So basically what you are saying is that in your view copyright is something that will motivate people to create things and that without it people are less likely to do things. That's not what I said, as I did not say anything about motivation, for one. It is not a bad argument in itself as long as we speak about work for hire. Culture is a different phenomena which cannot be limited to a collection of works for hire. This is why I do not believe this argument works when we speak about culture. You cannot separate culture from money in any money-using society. Does it work when we speak about a caste of professional creative people? It does, definitely. But is the caste of professional creative people so desirable to society? This is another question we can discuss. As long as people have to earn money for a living, combined with the tendency to require a huge amount of time at that, the question is then if people being able to invest a majority of their time, effort and skill in creative endeavors is desirable. I'm not a fan of capitalism and even less so of long work-days, but it's hard to even think of a better system that takes human nature into account, to not even speak of establishing one. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] sliders/fans
On 12/07/2011 09:03 PM, David Robillard wrote: It's more like the distance along the minor axis controls sensitivity, and the actual value change is always along the major axis? Oh, I thought that's what happens with fan-sliders already ... and I should know ;) The 3D application Houdini has controls that were one of inspirations. It has been a long time, but afair, you get a box with several rows. Values are decreased by dragging to the left and increased by dragging to the right. The choice of row determines if a certain distance equals 0.1, 1, 10 ... units (or similar). -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] FOSDEM 2012
On 01/04/2012 12:28 PM, Nils wrote: who is going to attend the FOSDEM Open Source Developers meeting in Brussels(Belgium) on 4./5. February? http://fosdem.org/2012/ I will most likely be there on Saturday. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 07:36 AM, Albert Graef wrote: I don't see why an OSC track should make any assumptions about the semantics of OSC messages. For optimized representation and editing. Avoiding artificial restrictions can give you both freedom and clumsiness ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Plugin buffer size restrictions
On 05/28/2012 12:52 PM, Fons Adriaensen wrote: They are not that stupid. And they didn't need me to find out the things they did not like: extensions being created and then deprecated, extensions that 'exist' on some web page but are implemented nowhere, tutorials that start with saying that everything has changed and they should be ignored, etc. LV2 may suffer from those issues, all hard to avoid for a free software project that moved slow at times, due to a lack of total qualified developer time. If nobody takes control, it's yucky anarchism. If someone does step up, he becomes a "dictator" and there will be people who call him a fool for taking choices different from those they would have taken, but didn't and likely won't. It's like you are asking again and again: "David and Co, why didn't you just publish a complete specification at once, one all important plugin and host authors would agree with, magically. As you did not do this, why don't you throw away what you have to do it now?" "Oh, and David, why don't you at least mention all the negatives, every-time you mention the project that your investing so many hours (weeks, months ...) in?" As I understand it, what you are insisting on would require a change to the core of LV2 and invalidate everything out there. Which would lead to deprecation and outdated documentation on a much larger scale. All that to gain something the creators of several other standards apparently didn't consider important or at all. I think it is the impression that you keep measuring LV2 against an hypothetic solution that irritates not just David. Especially if it sounds like that hypothetic solution has to somehow appear at once, without the friction of experiments and visible social interaction. "LV2 Creators, why aren't you a company and invest a few man-years , working in secret, to then publish a *complete* spec and reference implementation at once?" It would be nice, if you could limit your further input in LV2 matters, if any, to things that LV2 developers can act on, realistically. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Plugin buffer size restrictions
On 05/29/2012 01:03 AM, Fons Adriaensen wrote: Things are different if the control data was not generated 'live' but e.g. created in an graphical automation editor using a displayed recorded waveform - the one the plugin will operate on - as the time reference. In that case users will not expect an offset of control w.r.t. audio. But otoh, even such data will probably be edited by 'trial and error' - by listening to the result instead of trusting the graphical input blindly - which means that even in this case the user will somehow compensate for the delay (if it is short enough). The graphical environment would lead to the expectation that control points in the automation editor and the waveform view are strictly in one timeline, no delay. It should be possible and provided for, that parts of automation recorded live and parts created graphically are mixed and also that recorded automation will be edited. I guess that would mean that an automation editor has to show the result of the control values, not the values themselves. So on playback, the automation would be send with negative delay (requiring latency on the "Play" command ...) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Achievement of GMPI Requirements
On 07/31/2012 10:13 PM, David Robillard wrote: I have adapted the GMPI requirements final draft document to a comparison with the current state of LV2: http://lv2plug.in/gmpi.html Great job! Besides dynamic ports, most interesting to me seems to be the Instruments section, http://lv2plug.in/gmpi.html#sec_3.17 In short: per voice control of any parameter. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO)
On 08/22/2012 01:50 AM, David Robillard wrote: 1) Fork these plugins and add a tuning frequency port, in Hz, which makes the current reality of them using absolute octave signals go away. The avwlv2 project will have to adjust the ported AMS modules likewise. Though your plugins do not currently do this, you now seem to think this is the correct solution? 2) Define an absolute unit in octaves with a standard, absolute, center frequency. This is current reality, except the "define" part, and the 'standard' is a weird frequency. I would prefer 1), because 1/octave might be useful for modulation, but just complicates matters if the task at hand is setting an oscillator to a specific frequency. One could even argue that oscillators should not have 1/octave ports at all, but that there should be a plugin that takes a 1/octave modulation input, a Hz base input and delivers a resulting Hz output. The DRY principal applied to plugins. Even for modulation, a plugin/infrastructure that allows the user to map any value range to a frequency modulation range in semitones could be far friendlier and does not necessarily need 1/octave behind the scenes. I doubt consistency with the original plugins will matter in practice at all. The added workload for you sucks, of course and only you can weight that aspect of it, David. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] CC-by-sa licensed samples/instrument plugins
On 08/31/2012 05:44 PM, Nils wrote: But for Creative Commons ShareAlike? Is music a derived work from samples under cc-by-sa? From http://creativecommons.org/licenses/by-sa/3.0/legalcode: "'Adaptation' means a work based upon the Work, or upon the Work and other pre-existing works (...) or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original (...)" In this context, I lean towards considering music that uses samples to be an adaption of those sample. However, the license is clearly written with remixes and combinations in mind, where you either stay in the same category as the licensed work (e.g remix music to music) or combine categories (add music to video). It is no written for works that are meant to be "raw" material, like fonts or sample-packs. In this sense, your question has no clear answer, which is worse than a Yes. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] So what do you think sucks about Linux audio ?
On 02/05/2013 03:58 PM, Dave Phillips wrote: So, in your honest and bold opinion as user and/or developer, what do we lack most and what can we do without that we already have ? Enlightenment. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Ardour "sampler" feature?
On 26.08.2014 19:39, Devin Venable wrote: My dream feature? Click on segment, select "convert to sample" and a new midi track appears linked to a plugin sampler, ready to play. I could have used something like that a few times. Being an architecture astronaut by hobby, I've been wondering about the differences and commonalities between (audio-)sequencers and samplers. In both cases you have an abstraction on top of actual audio-files and playback start/stop. But playback is parameterized differently. The sequencer has a timeline position and transport state, while the sampler takes notes (and potentially a bunch of control events). Lets think of a track in a sequencer to actually be a mapping of a playlist to a playback graph. The playlist can be reduced to a sequence of events. The playback graph consists of at least a playback engine and may contain an effect chain. In typical sequencer use, for pure audio tracks, a playlist will contain regions that map to audio-files. That part of it can be reduced to a sequence of audio-sample-values, as main input to the playback engine. There may be other events/automation, all being inputs to the playback graph. The general idea is that you always deal with sequences of events as inputs to a playback graph. Now all of that is coupled to a single, global playback control, consisting of transport state and timeline position. What if you could choose to decouple tracks from global control and make them take note-events for playback control instead? If the playback engine can variate playback speed in relation to note-value, you have a basic sampler. If the playback engine also offers realtime pitch-shifting/time-stretching and formant control, you have wonderland. Note that you would not be limited to control a decoupled track's position and state by notes. There could also be direct control with start/stop/speed (including negative) and locate/go-to events. Tracks that play tracks ... Mmwuhahahaha! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Units (was: Re: Experience driven design and Linux Audio)
On 01.10.2014 22:19, Fons Adriaensen wrote: The many times I've had to set a delay time the most convenient unit could have been samples, millisecs or meters (at the speed of sound), depending on the context. I've never had the need to set it in beats. Which are not even a fixed unit but require the delay processor to know the current bpm value. Could be done in an app or plugin that mainly deals with beats, not in a general- purpose plugin. Sounds like a piece of functionality that should be covered once, for all, ideally. As some kind of unit conversion/entry lib/plugin. For every plugin time parameter where any of the provided units make sense, there would be an input field with a default unit for that specific parameter, and a way to switch between samples, ms, s, d:h:m:s, ..., meters at [some] speed, beats at hots-provided bpm. The space required and the shear number of options would infer a cost with no payback for some users, but otherwise could make for a great user experience ;), where: - no distraction is caused by having to do workarounds, even just having to get out the calculator. - the consistency across plugins/apps means the interface can be learned once, with gains in efficiency on repeated use. Another candidate would be frequency/pitch. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 23.04.2015 12:01, Gianfranco Ceccolini wrote: I think that the point that most of us are missing is that, prior to decide the features on a particular product (a software in the discussed cases), one needs to decide THE TARGET AUDIENCE of such product. There are cases where defining a target audience is possible and beneficial, sure. Once you allow a small number of distinct audiences, you get a little farther. For some generic and/or complex products, things get messy fast. Just think of possible audiences for Blender: game developers, hobby vertex pushers, 3d printed bunny enthusiasts, product designers, professional illustrators and 3d animation specialists (coffee logisticians, modelers, texture artists, rigging and animation artists ...) ... Even though you can expect conflicts and issues due to the sheer number of features, Blender can work for all of them. Note however, than some people think its unnecessarily strange and complicated, while others think it's basically sliced bread for 3D. Oustide of marketing, I think it's not that important if you can assume your typical user to be Granny Smith, Tom Broman or little Susie. Truly important are the tasks to be accomplished, the work environments and the frequency and duration of use. Guess how the last 2 points relate to the different impressions people have of Blender. Aside of all that, every single user being human has limited memory, a locus of attention easily pulled away by an important message ... or just a distraction, is better at recognizing than recalling, forms habits, is slowed down when having to consider options, ... and so on. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 23.04.2015 11:50, Vytautas Jancauskas wrote: Who would think that having to operate a circular knob by moving the mouse in a little circle is convenient? It's also a bit harder to implement. Is there some argument for it I am not aware of? Properly done radial knobs do not force you to move the pointer in a little circle, but allow you to increase the distance. This way, you get adjustable precision. In my own experience, this can work very well for parameters that have a huge range (i.e. _many_ steps) and control something sensitive to the smallest changes. One issue is the placement of the knob relative to the edges of the screen and what you do when the pointer (ignoring touch) reaches them. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 23.04.2015 22:59, Fons Adriaensen wrote: And in the case I mentioned (flight deck displays and user interfaces) were are talking about*specialists* in ergonomics who have conducted a not one but a series of studies and experiments involving a large group of*expert* users and costing tons of money. And the result is quite different. So whom do you think I should believe ? Writing a letter sitting safely at a desk leads to slightly different requirements for a UI than piloting an airplane ... You do not seriously believe common aspects of mainstream desktop environments and core applications like the behavior of radio buttons, checkboxes, menus, dialogs and so on came to be without many rounds of research and refinement, do you? There may admittedly be a problem with cargo-cult guideline writing, copying without taking first principles into account. Plus the people now working at Microsoft, Apple or Gnome and KDE are at risk of forgetting some of the things the GUI pioneers already understood. Now in intensity and information load, applications like Blender or Ardour may come closer to a cockpit than a spreadsheet application does. But I guess the glass cockpits, just the screens, are not meant for direct manipulation, which surely influences the design. Centralized pure display combined with a shitload of buttons and doodads do not lend themselves as a model for a multi-purpose computer UI. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 23.04.2015 21:55, Len Ovens wrote: That is why being able to adjust with both horizontal and vertical movement is a plus. Take a look at zita-mu1 for an example. It is also important to continue watching the position of the mouse when it leaves the application window. Yes. If the linear knob happens to be too close to a corner of the screen, both part of the vertical and the horizontal range may be out of screen, though. Changing direction forces you to spend attention instead of relying on autonomous movement, trained by repetition. With pointer-based usage, you can allow the pointer to go beyond the edge. Some 3D application will have the pointer appear on the other side, as if it traveled through a portal. But with touch, you are out of luck, have to move the active area and allow the finger to be repositioned. I think in many cases, horizontal sliders with labels and numerical values inside the slider area, are the better approach. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 24.04.2015 23:40, Fons Adriaensen wrote: Consider a button that toggles between 'stop' and 'play'. Does it show the current state of the player, or the one you get when you click on it ? Yes, a classic. It's the general problem that using any toggle-action successfully requires the user to be aware of the current state. That might sound like a non-issue seen in isolation, but if a user has to deal with lots of such states over a long period of time, mistakes will happen. At the very least frustrating double and triple triggering. The reason to use one toggle button over 2 action buttons is saving space. Likewise, one shortcut over 2 shortcuts. A DAW can get away with Play/Pause toggling, but less often changed states that affect other actions are more troublesome as toggle. I mean to recall that Rhino3D has buttons that will always enable / keep enabled something on left click and will always disable / keep disabled on right click. Regarding ambiguous icons on toggle buttons that might display either state or action: If you can't avoid them, didn't find icons that imply action or state, the last line of defense is convention. Always state or always action. Similar situation with 'slider switches' which show 'on' or 'off' on the flat part. If you have no other feedback, the state of the button or slider gives you a very ambiguous hint at best. The blind copying of Apple's sliding switches is one of the saddest things to happen in recent GUI design. I for one can't take anyone serious who thinks this is acceptable: https://afaikblog.files.wordpress.com/2013/01/date-and-time.png If one wanted to infer a guideline from that screenshot, it could be: "Make sure there is a huge gap between labels and associated widgets. This slows the user down to avoid stress and gives his eyeballs a nice workout." We already know a solution since decades. Checkboxes with their identifying graphics on the left side. Taking touch into account should not mess up pointer-based use. If you can't make sure of that, maybe a hybrid is a bad idea? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 25.04.2015 09:50, Will Godfrey wrote: One of my pet hates is erratic implementation of tooltips... that can't be disabled! I'm not sure where I saw it ... an interesting alternative is to have a status line in a static location. It can be used for tooltip text, parameter values and perhaps a few messages. A drawback is of course the distance between the line and whatever the pointer is hovering. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Implementing software knob behaviour
On 16.05.2017 09:25, Christopher Arndt wrote: - What should I use as the reference point for finding the distance of the movement? The centre of the knob or where the first touch event occurred? First touch. Elsewise, if that point is above the center and the cursor/finger moves down, what are you going to do until the center has been passed? - Should I apply the distance to the value directly or use the distance as a relative value (i.e. increment / decrement to the value when the touch started)? If the former, how do I prevent value jumps? I don't quite understand what you are trying to describe here. I think the behavior should be as if a slider was brought up, with the current value, positioned such that the indicator (top of the value bar) is right below the pointer/finger. You should probably actually display a slider. For touch, it's worth thinking about not (only) showing something right in place, as the finger/hand may obstruct it. The slider area may end up partially off screen. You could rely on the user to slide twice if they want to reach an extreme in such a case. Or implement a scroll-fully-into-view feature. With a mouse, you could allow the pointer to go off-screen / wrap-around (this works quite well in the 3D app Blender). At the same time the pointer goes over the edge, the slider could be moved appropriately. For a touch interface, you'd have to move the slider as the finger approaches the edge, though. In case inspiration regarding the visuals is welcome: https://thorwil.wordpress.com/2007/04/27/not-knobs-5/ https://thorwil.wordpress.com/2007/05/01/fan-sliders/ -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On 05.12.2017 17:21, Louigi Verona wrote: I have to note you have no statistics, either, but of course that doesn't stop you. It's as if you would ask for a level of sobriety, factuality and precision that you yourself refuse to offer, while pretending otherwise. I have reacted to the initial post because a person was claiming that because *a problem* on a Mac happened - that means that everything which is a Mac is now a problem. For a person of such eloquence, it seems strange that your reading comprehension would fail you so terribly or that you would suddenly try your hardest to be the opposite of pedantic. Jörn's post was an openly emotional reaction to a situation that came about because of a specific set of features that you get with an Apple laptop, if you want them, or not. It's a fact that there is a specific risk because of those features. So if you are that hell-bent on boiling it down, the statement would be: "There is a specific problem with every (since a certain generation) Apple laptop". Anyway, ignoring the mood set with hyperbole like "... for I have sinned", going all pseudo-analytical instead, is rather tone-deaf. I for one, consider the case interesting and the way it was brought forward entertaining. My thanks to Jörn, who doesn't deserve such persnicketiness! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAM
On 20/11/2018 00.44, Spencer Jackson wrote: I've been happy with Archive.org for hosting the Open Source Musician Podcast. We could create a collection there. That would be very convenient, as I already have all my tracks there. Tagging them all with "Linux" as a Topic wasn't the most clever thing to do, as search results for that are "polluted" with podcasts ;) My tracks are in 10 collections now, most of which or of the "Usernames Favorites" kind. I wasn't even aware of that, until looking just now. Given lots of those, the visibility of a "Linux Audio" collection would be very low, it seems. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Open Source Design (paid and pro bono design)
On 29/11/2018 17.32, Louigi Verona wrote: Interesting that on their goals page they never mention "users" or "customers". So how are they going to understand what works if users are never consulted? That's clearly up to every single project. So from the point of view of "Open Source Design", the question is what works or doesn't work regarding designer involvement and designer-developer interaction. Now one may complain that the Why is kinda missing. Obviously there's an assumption that "opening up the design process" and so on is a good thing that doesn't need to be explained. It is then up to said designers and developers to care about user feedback, iterations, testing. Or not. One may concentrate on general fitness for purpose, pay not too much attention to the subset of users that gets loud, and lack the resources to do real user testing, anyway! ;) The last time I got across that job listing, the few paid items were too old already. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Resampling: SOX vs FFmpeg
On Thu, 23 May 2019 10:58:54 +0200 Louigi Verona wrote: > 2. Does it make sense to resample to 44100 or to 48000? AFAIR many soundcards and onboard solutions work with 48000 internally and have to resample any 44100 source. -- Thorsten Wilms ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] A GUI request
On Tue, 7 Jun 2022 00:06:08 +0200 Fons Adriaensen wrote: > Simple fact is that all popular GUI toolsets are targeted to developing > 'office' > or 'social' type of applications and completely fail to address the needs for > anything outside that limited scope. There is much more to this than just the > choice of colors. Indeed. It’s a shame, as office-type applications could benefit from higher standards of providing information at a glance and efficient means of control (even at the cost of being less obvious). > I've been involved in creating displays used in aircraft cockpits and similar > technical environments. Almost all of the 'standard' GUI design guidelines > (as advocated by 'computer science' academics) have been shown to be either > irrelevant or just plain wrong for such applications. That probably includes > graphical interfaces for pro-audio systems. So far I thought the differences are all about much higher requirements on readability at a glance and stableness. More contrast, avoiding superfluous styling, no deep layering. Being able to rely on training much more. Fons, do you have examples of such guidelines that don‘t work for cockpits, that may surprise the layman? -- Thorsten Wilms ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
