Re: [LAD] libsuil
On Wed, 2011-02-23 at 20:11 +, Rui Nuno Capela wrote: [snip] > are you saying that this suil api will get it implicit and integrated > into slv2? in a matter of days? i've looked into the "suil.h" and it > makes perfect sense... I've done this now[1]. The half-baked collection API in Suil as of my last post was clumsy and out of place. I've removed all that, so Suil is exclusively for instantiating (and possibly wrapping) plugin UIs (deciding which UI to instantiate is the user's problem). SLV2 now (optionally) depends on Suil. The API changes are minimal; host authors just need to switch from the now-deprecated slv2_ui_instantiate to its replacement, slv2_ui_instance_new. This new function takes the same parameters plus an additional widget type parameter which specifies the type of widget the host expects. Cross-toolkit embedding should then magically work. -dr [1] http://dev.drobilla.net/changeset/3022 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] libsuil
On Thu, 24 Feb 2011 04:19:05 -0500, David Robillard wrote: On Wed, 2011-02-23 at 20:11 +, Rui Nuno Capela wrote: [snip] are you saying that this suil api will get it implicit and integrated into slv2? in a matter of days? i've looked into the "suil.h" and it makes perfect sense... I've done this now[1]. The half-baked collection API in Suil as of my last post was clumsy and out of place. I've removed all that, so Suil is exclusively for instantiating (and possibly wrapping) plugin UIs (deciding which UI to instantiate is the user's problem). SLV2 now (optionally) depends on Suil. The API changes are minimal; host authors just need to switch from the now-deprecated slv2_ui_instantiate to its replacement, slv2_ui_instance_new. This new function takes the same parameters plus an additional widget type parameter which specifies the type of widget the host expects. Cross-toolkit embedding should then magically work. great! i'll test this stuff asap. oh, another question on wishing to keep compile-time (#ifdef's:) retro-compatibility with previous libslv2 releases: is it correct to assume that "slv2_ui_instance_new" symbol is determinant to whether we're in presence of this newer libslv2 version? if not, what would be the correct method, iyo? cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAD Activity (WAS: [ANN] IR: LV2 Convolution Reverb)
On Wed, Feb 23, 2011 at 11:40:01AM -0500, David Robillard wrote: > On Wed, 2011-02-23 at 13:01 +0200, Stefano D'Angelo wrote: > > 2011/2/23 Alexandre Prokoudine : > > > On 2/22/11, David Robillard wrote: > > > > > Before I totally forget about it... I think it might be a very clever > > thing to do to have some web-based thing (wiki or whatever, ideally a > > social network kind of thing) were LAD people can notify of what they > > are working on and what are their plans, so that it's easier to: a. > > know about it and b. start cooperations, etc. > > There's Planet LAD, made for this reason a while ago. RSS and a planet > is definition The way to do this, IMO. I am subscribed to it in my feed > reader and keep up to date. If everything interesting going on was > pushed on the feed, it would indeed be very nice... i think the planet is too big already. its a linux audio planet. not a linux audio DEV planet. maybe it would make sense to somehow split it ? or create a dev planet where only development stuff is aggregated ? > > > For example, Dave is doing lots of stuff that I plan to reuse, but I > > only know it because I happen to lurk on #lv2 on freenode from time to > > time, and the same goes for lots of stuff I'm seeing coming out > > lately. > > Yeah, been meaning to blog more, what can I say :) > > I'll throw one out today about the UI stuff, anyway. Qt plugins embedded > in Ingen working at least somewhat via a library, with minimal nuisance > on either end. > > -dr > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb
On 23 February 2011 23:55, David Robillard wrote: > They're all in my LAD meta-repository: Ah, externals. LGPL I see -- I've no problem with that in principle, but it would complicate matters a bit (both Dataquay and Redland being BSD). > if you're just interested in Turtle + in-memory model That's essentially all I use -- Dataquay does a basic job of wrapping SPARQL as well, but a case could be made for that to be optional. Chris ___ 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 Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis wrote: > and to answer that question: what happened was huge great > boatloads of data that need to be shovelled around between all the > relevant components, complicated synchronization in both the backend > models and the user interfaces of all the relevant components, and a > general disdain for complex *systems* when one can settle for merely > complex programs. There's no doubt that many users or potential users want the 'all integrated' DAW combining audio, sequencing, invasive effects, etc. required to produce a particular type of music (and some other content, e.g. ads) that happens to have a wide audience. And consequently a large number of people wanting to be involved in making it. OTOH, this does not mean that some other people (who may be a minority) can't have other needs, nor does it provide good reasons to imply that they are in some way retarded, out of sync with their time, old-fashioned or whatever. 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. 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. And the most perverse consequence of preferring complex apps to complex systems is that it becomes near impossible to modify them to individual or 'minority' needs. To all effects, Ardour is to me as closed as Protools is, just because it has become so complex rather than just big, and I can't spend a year on learning all of it. I'm at the mercy of its developers, and they have good reasons to ignore my needs as they have done for years. So the only remaining advantage is that it is free as in free beer. 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. Ciao, -- FA ___ 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 Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote: > Entirely Redland free. I hand-wrote a Turtle parser and serialiser. > > In short, it's been a PITA for everyone in numerous ways since day one. Congratulations. I mean it. This is probably the best move in the entire history of LV2. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAD Activity (WAS: [ANN] IR: LV2 Convolution Reverb)
Stefano wanted to know whether someone was starting something he was interested in because he might want to contribute, if I understood him correctly. But I don't think it is really common practice (or even good form?, but that's very debatable) to announce something if you are not ready to release some code, many things can happen in-between (loss of interest, unexpected -heh- lack of time, realization that there may be better options...) and a premature announcement never fulfilled might end up being worse than no announcement at all, since people might refrain to take on a similar project to avoid duplicating efforts. A release, in whichever stage, at least shows some commitment behind the project. For released software there's already LAA (+planet mirror), as Robin says. For unreleased one, I meant with my previous message that perhaps it might be better to give a shout here: "hey, I miss such and such and I am considering putting some hours into making it happen. A search for similar projects didn't yield any results, has anyone something going already along this line?" But I dunno, it was just a minimum-effort proposal, lazy bugger that I am. I see how you might perhaps, maybe, want to jump in something even if you never thought of starting it, if you find its declaration of intentions sufficiently inspiring. Luis ___ 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] [ANN] IR: LV2 Convolution Reverb
>> 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? Again that difference is not really signficant. Paying a license is an investment that has some return, or maybe hasn't, and that is the only thing that matters in a professional context. And the cables and plugs wear out as well and have to be replaced every now and then. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAD Activity (WAS: [ANN] IR: LV2 Convolution Reverb)
Excerpts from torbenh's message of 2011-02-24 11:21:36 +0100: > On Wed, Feb 23, 2011 at 11:40:01AM -0500, David Robillard wrote: > > On Wed, 2011-02-23 at 13:01 +0200, Stefano D'Angelo wrote: > > > 2011/2/23 Alexandre Prokoudine : > > > > On 2/22/11, David Robillard wrote: > > > > > > > Before I totally forget about it... I think it might be a very clever > > > thing to do to have some web-based thing (wiki or whatever, ideally a > > > social network kind of thing) were LAD people can notify of what they > > > are working on and what are their plans, so that it's easier to: a. > > > know about it and b. start cooperations, etc. > > > > There's Planet LAD, made for this reason a while ago. RSS and a planet > > is definition The way to do this, IMO. I am subscribed to it in my feed > > reader and keep up to date. If everything interesting going on was > > pushed on the feed, it would indeed be very nice... > > i think the planet is too big already. > its a linux audio planet. not a linux audio DEV planet. > > maybe it would make sense to somehow split it ? > or create a dev planet where only development stuff is aggregated ? I agree. Previously http://planet.linuxmusicians.com/ was the more general one and http://planet.linuxaudio.org/ the more dev one. Anyway, I agree that there should be a split of sorts and someone should moderate them in the sense that he should decide what goes where. Besides that a headline-view rather than whole blog would be handy to keep an overview. ___ 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: Spending some money on Protools is not really different to doing the same for a kilometer of microphone cable or some XLR plugs. imnsho, this simile only holds if you intend to hang yourself with the microphone cable. ___ 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:47 PM, Fons Adriaensen wrote: On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote: Entirely Redland free. I hand-wrote a Turtle parser and serialiser. In short, it's been a PITA for everyone in numerous ways since day one. Congratulations. I mean it. seconded. it used to be quite tricky to chase the correct versions of redland and its various dependencies, and i recall that at least one library down dependency hell road would require hefty manual massaging to even compile, at least on the distros i tried it on. > This is probably the best move in the entire history of LV2. now that's a bit nasty :) ___ 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 Thu, Feb 24, 2011 at 6:43 AM, Fons Adriaensen wrote: > On Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis wrote: > >> and to answer that question: what happened was huge great >> boatloads of data that need to be shovelled around between all the >> relevant components, complicated synchronization in both the backend >> models and the user interfaces of all the relevant components, and a >> general disdain for complex *systems* when one can settle for merely >> complex programs. > > There's no doubt that many users or potential users want the > 'all integrated' DAW combining audio, sequencing, invasive > effects, etc. required to produce a particular type of music i don't agree with you that its about a type of music. it is about the difference between some different ways of producing music, and not just two of them. there are certainly approaches to making music that are not well served by a DAW. but they are approaches to the production of music, not kinds of music. > OTOH, this does not mean that some other people (who may be > a minority) can't have other needs, nor does it provide good > reasons to imply that they are in some way retarded, out of > sync with their time, old-fashioned or whatever. of course not. but the question still remains whether that particular group of people would rather deal with a complex app that is tuned to their needs or a complex system that can, optionally, be tuned to their needs. the question doesn't change. there are people who are far happier to deal with PD or Max than with a collection of plugins inside a modular host - its the same kind of distinction. > 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. i think you're wrong. its not that a DAW represents one particular musical culture, it just reflects some cultures of music production and not others. the notion that there is ever "one tool" for a task as incredibly varied as producing music is absurd. nobody with half a brain suggests that any DAW can be that tool. > 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. i think you over-estimate the impact of this, although i agree that its not zero. > And the most perverse consequence of preferring complex apps > to complex systems is that it becomes near impossible to modify > them to individual or 'minority' needs. i return to my earlier points above. why would you imagine that tinkering with "the all inclusive universal DAW" is ever going to produce the right tool for each individual or minority need. the whole concept is just misformed. > learning all of it. I'm at the mercy of its developers, and > they have good reasons to ignore my needs as they have done > for years. So the only remaining advantage is that it is free not to be mercenary about it, but the difference is that if your needs were that important and not being met by anything available to an intolerable degree, you could (or some organization could) choose to pay to have your needs met and not face any licensing/access issues in doing so.. the open source nature of ardour, like the open source nature of emacs and firefox and linux, doesn't mean that its going to cater to everyone's needs as-is. the difference with protools is that you can't even consider this as an option. is that a big difference? it depends on whether a tool like ardour stands any hope of being the solution. for people who like to make music with renoise or with ensembles of cassette players and violins played with pencil erasers, it very well may not be. ___ 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 Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen wrote: > There's no doubt that many users or potential users want the > 'all integrated' DAW combining audio, sequencing, invasive > effects, etc. required to produce a particular type of music > (and some other content, e.g. ads) that happens to have a > wide audience. And consequently a large number of people > wanting to be involved in making it. That sounds like an intentionally badly hidden sarcasm. > OTOH, this does not mean that some other people (who may be > a minority) can't have other needs, nor does it provide good > reasons to imply that they are in some way retarded, out of > sync with their time, old-fashioned or whatever. MIDI tracks in A3 are not forced to users at knife-point. > 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. The question I'm inclined to ask is whether you ever saw A3 live. Because, really, until you choose to add a MIDI track, the related functionality barely exposes itself. > And the most perverse consequence of preferring complex apps > to complex systems is that it becomes near impossible to modify > them to individual or 'minority' needs. http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-both-mac-and-linux-harrison-mixbus/ "Coming from the rarified world of high-end audio systems, we recognized a lot of the same qualities in Ardour. Some examples: “customization on a truly deep level is important for enterprise-class facilities” …. stuff like that." You had it coming, Fons. Alexandre Prokoudine http://libregraphicsworld.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAD Activity (WAS: [ANN] IR: LV2 Convolution Reverb)
On 02/23/2011 11:16 PM, David Robillard wrote: On Wed, 2011-02-23 at 20:05 +0100, Robin Gareus wrote: Note: all posts to LAA are being moderated. Once they make it through moderation, the message will get on the linuxaudio.org front-page and is automatically added to planet LAD. If you prefer to blog and would like the blog to be included in planet.linuxaudio.org: read the sidebar of planet LAD. For the record, I have found it frustrating that if you announce a release on LAA, and blog it, it ends up on Planet LAD twice. I suppose I just shouldn't push those announcements to the RSS feed picked up by Planet LAD, but.. well, it /is/ LAD :) i don't really mind, unless the blog title is such that i can't readily identify it as a duplicate of the LAA announcement in my simplistic rss reader (a firefox live bookmark). ___ 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 Thu, Feb 24, 2011 at 8:07 AM, Alexandre Prokoudine wrote: > http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-both-mac-and-linux-harrison-mixbus/ > > "Coming from the rarified world of high-end audio systems, we > recognized a lot of the same qualities in Ardour. Some examples: > “customization on a truly deep level is important for > enterprise-class facilities” …. stuff like that." Well, *they* would say that. They like Ardour. And they live in Nashville. Say no more, eh? :) ___ 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 Thu, Feb 24, 2011 at 04:07:41PM +0300, Alexandre Prokoudine wrote: > On Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen wrote: > > > There's no doubt that many users or potential users want the > > 'all integrated' DAW combining audio, sequencing, invasive > > effects, etc. required to produce a particular type of music > > (and some other content, e.g. ads) that happens to have a > > wide audience. And consequently a large number of people > > wanting to be involved in making it. > > That sounds like an intentionally badly hidden sarcasm. Absolutely none intended. It's just a fact. > > OTOH, this does not mean that some other people (who may be > > a minority) can't have other needs, nor does it provide good > > reasons to imply that they are in some way retarded, out of > > sync with their time, old-fashioned or whatever. > > MIDI tracks in A3 are not forced to users at knife-point. I never said they were. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Realtime threads and security
Hello Robin, On 02/23/2011 08:28 PM, Robin Gareus wrote: > On 02/23/2011 11:22 AM, Olivier Guilyardi wrote: >> Hi, >> >> On 02/17/2011 10:53 PM, Robin Gareus wrote: >> >>> /proc/sys/kernel/sched_rt_runtime_us >>> /proc/sys/kernel/sched_rt_period_us >>> >>> /Documentation/scheduler/sched-rt-group.txt >> There's something which confuses me. But I'm not sure how this realtime >> period >> settings relate to the audio I/O period. > > It only does iff the audio-I/O thread (or process) is executed with > realtime privileges (`man chrt` - man `pthread_setschedparam` ). Hmm.. realtime privileges are a given in this discussion. Yes, the idea is to have the audio I/O thread run in realtime, and access the audio hardware through the Android audio HAL, namely libaudio, instead of say, ALSA. ALSA actually is the backend of libaudio on certain devices, but only a minority. So, for more portability, I'm investigating whether it would be possible to read and write using the libaudio API from a realtime thread. > if you have a RT_PREEMPT kernel you can also raise the priority of the > audio-device interrupt handler. I need to look at that, but I'm not sure if this is relevant in the case of libaudio, as it is when using ALSA. The audio hardware which is integrated into these all-in-one chips seems to be sometimes very different from conventional soundcards. And in many cases there are rather non standard kernel drivers under libaudio. So I'm not sure whether one can think in terms of interrupts on Android mobile systems. But I suppose it makes sense in the majority of cases. > Well, it's a bit more complex than that.. not sure if you can go that > way on Android easily. Since you mention realtime privileges above, I suspect some confusion here. This discussion is not about capturing and playing audio using the Android public API. It is about improving low level Android audio support, by: - either writing some patches for the mainstream Android source code - or dropping some external module on systems where the user has acquired superuser privileges (rooted devices). For the later, what module? Well, this could for example be JACK. This should be possible to a certain extent. Now, say I'm only focusing on playback now. Is there something wrong with calling a blocking output API from a realtime thread as I ask below? >> On Android, the closest that one can get to hardware in a more or less >> portable >> way is libaudio [1]. It's Android's audio HAL. This API exposes blocking >> read() >> and write() calls, with fixed buffer sizes (input and output buffer sizes >> generally do not match, but that's another problem). >> >> So, this may be a silly/newbie question, but can one access this blocking API >> from a realtime thread? What will happen when it blocks? How does the >> read/write >> period relate to sched_rt_period_us? >> >> [1] http://source.android.com/porting/audio.html -- Olivier ___ 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 Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote: > i don't agree with you that its about a type of music. it is about the > difference between some different ways of producing music, and not > just two of them. there are certainly approaches to making music that > are not well served by a DAW. but they are approaches to the > production of music, not kinds of music. Well, 'type' or even 'a particular type' can refer to a leaf node in the taxonomy or to a quite solid branch of it. The are classes of music that depend on sequencing etc. in order to be produced at all - that's why people involved in them want those features in the first place. I don't think it's wrong to call this 'a particular type of music', the type is defined by its dependence on those tools. > i think you're wrong. its not that a DAW represents one particular > musical culture, it just reflects some cultures of music production > and not others. Indeed, see above. > the notion that there is ever "one tool" for a task as > incredibly varied as producing music is absurd. nobody with half a > brain suggests that any DAW can be that tool. Then maybe the term 'DAW' is misnomer. I wouldn't call a tool that can't do simple four point editing an 'audio workstation'. The sad fact here is that Ardour probably has 99% of the code required to do it. The final 1% is missing because the concept doesn't exist in the mindset of the developers. And by that I don't want to suggest they are too stupid for it (as some may choose to interpret my words), but just that they are focussed on a 'type', 'class', 'category' or whatever you may call it of music that doesn't require it. > not to be mercenary about it, but the difference is that if your needs > were that important and not being met by anything available to an > intolerable degree, you could (or some organization could) choose to > pay to have your needs met and not face any licensing/access issues in > doing so.. Well, I could pay or I could offer my time as a developer. During the last five years I have several times offered to integrate decent multichannel or AMB panning into Ardour, provided I could team up with someone taking care of the GUI aspects (I'm a nitwit regarding writing for GTK). Nothing has happened. I've arrived at the point where it quite clear that if I want certain functionality I'll be on my own to implement it. Ciao, -- FA ___ 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 Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen wrote: > On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote: > >> i don't agree with you that its about a type of music. it is about the >> difference between some different ways of producing music, and not >> just two of them. there are certainly approaches to making music that >> are not well served by a DAW. but they are approaches to the >> production of music, not kinds of music. > > Well, 'type' or even 'a particular type' can refer to a leaf node > in the taxonomy or to a quite solid branch of it. > The are classes of music that depend on sequencing etc. in order to > be produced at all - that's why people involved in them want those > features in the first place. I don't think it's wrong to call this > 'a particular type of music', the type is defined by its dependence > on those tools. music is sound arranged in time (and optionally in space). i don't know precisely what you mean by sequencing, but that means that any production of music is going to involve arranging one or more of the following things in time: * carrying out physical movements * playback of existing recordings of audio * instructions (for a human and/or a machine) to do one or both of the above to the extent that computers don't carry out physical movement (much), any use of computers in the production of music means that it is going to involve the 2nd and 3rd options. both of them have been called "sequencing". ardour2 only does the second action right now; ardour3 adds the third (instructions for a machine). >> the notion that there is ever "one tool" for a task as >> incredibly varied as producing music is absurd. nobody with half a >> brain suggests that any DAW can be that tool. > > Then maybe the term 'DAW' is misnomer. I wouldn't call a tool > that can't do simple four point editing an 'audio workstation'. what you don't know (because you're not on IRC) is the question of N-point editing comes up a lot. i (and others) have argued (in my opinion quite successfully) that four point editing is a relic of an older workflow. others who have used 2, 3 and 4 point editing a lot on other systems have argued back. nobody has been persuaded to change their minds, and clearly nobody with the strong feelings in favor of it has been motivated thus far to implement it. > choose to interpret my words), but just that they are focussed > on a 'type', 'class', 'category' or whatever you may call it > of music that doesn't require it. actually, i think i can speak clearly for carl and myself (the two most active current developers; possibly most of the others too) when i say that we are focussed on the feedback that we get from people who repeatedly engage with us using the communication channels that we find most convenient for this work. is that perfect? no. but its the way things work out, at least for the last several years. the price of entry into the exclusive club that is #ardour is simply time, nothing more (or less). > Well, I could pay or I could offer my time as a developer. During > the last five years I have several times offered to integrate decent > multichannel or AMB panning into Ardour, provided I could team up > with someone taking care of the GUI aspects (I'm a nitwit regarding > writing for GTK). Nothing has happened. I've arrived at the point > where it quite clear that if I want certain functionality I'll be > on my own to implement it. if you can live with VBAP, this may interest you: http://ardour.org/files/vbappanners.png ___ 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 Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote: > On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen wrote: > > On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote: > > Well, I could pay or I could offer my time as a developer. During > > the last five years I have several times offered to integrate decent > > multichannel or AMB panning into Ardour, provided I could team up > > with someone taking care of the GUI aspects (I'm a nitwit regarding > > writing for GTK). Nothing has happened. I've arrived at the point > > where it quite clear that if I want certain functionality I'll be > > on my own to implement it. > > if you can live with VBAP, this may interest you: i doubt, that he can live with vbap. however, the ui should be pretty similar. so maybe he only needs to port amb dsp code. > http://ardour.org/files/vbappanners.png -- torben Hohn ___ 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 Thu, Feb 24, 2011 at 11:28 AM, torbenh wrote: > On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote: >> On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen >> wrote: >> > On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote: >> > Well, I could pay or I could offer my time as a developer. During >> > the last five years I have several times offered to integrate decent >> > multichannel or AMB panning into Ardour, provided I could team up >> > with someone taking care of the GUI aspects (I'm a nitwit regarding >> > writing for GTK). Nothing has happened. I've arrived at the point >> > where it quite clear that if I want certain functionality I'll be >> > on my own to implement it. >> >> if you can live with VBAP, this may interest you: > > i doubt, that he can live with vbap. > however, the ui should be pretty similar. > so maybe he only needs to port amb dsp code. i was planning to do that myself at some point soon, actually. i just have to get clear in my head whether i think any warning needs to exist somewhere that using it generates b-format. i also just discovered that VBAP doesn't do constant power panning between outputs, which means it probably needs to be thrown away. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] libsuil
On Thu, 2011-02-24 at 09:39 +, Rui Nuno Capela wrote: > On Thu, 24 Feb 2011 04:19:05 -0500, David Robillard > wrote: > > On Wed, 2011-02-23 at 20:11 +, Rui Nuno Capela wrote: > > [snip] > >> are you saying that this suil api will get it implicit and > >> integrated > >> into slv2? in a matter of days? i've looked into the "suil.h" and it > >> makes perfect sense... > > > > I've done this now[1]. The half-baked collection API in Suil as of my > > last post was clumsy and out of place. I've removed all that, so Suil > > is > > exclusively for instantiating (and possibly wrapping) plugin UIs > > (deciding which UI to instantiate is the user's problem). > > > > SLV2 now (optionally) depends on Suil. The API changes are minimal; > > host > > authors just need to switch from the now-deprecated > > slv2_ui_instantiate > > to its replacement, slv2_ui_instance_new. This new function takes the > > same parameters plus an additional widget type parameter which > > specifies > > the type of widget the host expects. Cross-toolkit embedding should > > then > > magically work. > > > > great! > > i'll test this stuff asap. > > oh, another question on wishing to keep compile-time (#ifdef's:) > retro-compatibility with previous libslv2 releases: > > is it correct to assume that "slv2_ui_instance_new" symbol is > determinant to whether we're in presence of this newer libslv2 version? > if not, what would be the correct method, iyo? Check for version >= 0.7.0. You could check that symbol too, I suppose. Regarding compatibility, I just had a thought: if I made a slv2_world_set_ui_widget_type or something, and stored that in the world, then the old function interface could do wrapping without breaking the instantiation function. Deprecating the old one (w/ GCC warnings) makes it more obvious to host authors what they need to do, though... I dunno... Cheers, -dr ___ 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 Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote: > what you don't know (because you're not on IRC) is the question of > N-point editing comes up a lot. i (and others) have argued (in my > opinion quite successfully) that four point editing is a relic of an > older workflow. others who have used 2, 3 and 4 point editing a lot on > other systems have argued back. nobody has been persuaded to change > their minds, and clearly nobody with the strong feelings in favor of > it has been motivated thus far to implement it. Then tell me how to do the following: replace a range A-B by another one C-D, with user controllable short xfades at the transitions, and so that everything to the right of B (which may mean disjoint regions) moves as required to make space for C-D. On all tracks, or some selected ones. With the option to listen to each side of a transition separately, and ajust it, without having to move away the other side. > actually, i think i can speak clearly for carl and myself (the two > most active current developers; possibly most of the others too) when > i say that we are focussed on the feedback that we get from people who > repeatedly engage with us using the communication channels that we > find most convenient for this work. is that perfect? no. but its the > way things work out, at least for the last several years. the price of > entry into the exclusive club that is #ardour is simply time, nothing > more (or less). I don't have the time to hang out in chat room all day. Fortunately I also have other things to do. You can of course choose to ignore this list and others, and emails, but using these are a far better use of my (or anybody's) time. > if you can live with VBAP, this may interest you: I'm generally not interested in VBAP. I provides the worst surround possible, even worse than most 5.1 panners. And in those rare cases where it would be a good solution, I can derive the required signals from a more universal encoding. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb
On Thu, 2011-02-24 at 10:48 +, Chris Cannam wrote: > On 23 February 2011 23:55, David Robillard wrote: > > They're all in my LAD meta-repository: > > Ah, externals. > > LGPL I see -- I've no problem with that in principle, but it would > complicate matters a bit (both Dataquay and Redland being BSD). I could perhaps be convinced to make it BSD since it's intended to be as widely usable as possible... the goal is to provide an enabling technology to promote Turtle/RDF, not the software itself, so that's appropriate. I'm making a single-file "amalgamation" ala SQlite as well, public domain / unlicense like they do might be a good choice too. > > if you're just interested in Turtle + in-memory model > > That's essentially all I use -- Dataquay does a basic job of wrapping > SPARQL as well, but a case could be made for that to be optional. I always wanted a programmatic query interface in Redland... having actual textual queries that need to be parsed every time is a bit silly in something like SLV2. Maybe one day I'll try my hand at a (simple than SPARQL) query engine, but it's a bit hard, and it turns out that doing triple queries and just iterating over those (possibly nested) actually makes much more clear code from a C coding perspective. Nested foreach style loops is much more natural than tabular query results for the type of code that uses LV2 (not that SPARQL style querying doesn't have it's uses, of course). -dr ___ 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 Thu, 2011-02-24 at 11:47 +, Fons Adriaensen wrote: > On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote: > > > Entirely Redland free. I hand-wrote a Turtle parser and serialiser. > > > > In short, it's been a PITA for everyone in numerous ways since day one. > > Congratulations. I mean it. This is probably the best move in the entire > history of LV2. Cheers :) I am not a fan of wheel-reinventing; at the time using the existing implementation seemed like the way to go, but... well, yeah. A burden has been lifted for sure. -dr ___ 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 Thu, 2011-02-24 at 13:08 +0100, Thorsten Wilms wrote: > 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? Oh, you havn't seen the latest improvements? The Ardour team noticed that, since the track type selector is a combo box, literally not a single pixel related to MIDI is shown during a purely audio related work flow. This is, of course, a big problem in terms of our greater mission to provide software that caters to the needs of precisely nobody while irritating everybody else. To resolve this situation, we now have an exciting new Clippy inspired assistant that hops around your screen begging you to add MIDI tracks constantly. If, after 20 minutes, you have still not created a MIDI track, Ardour will overwrite every .waf file found in your home directory with a 4/4 electronic kick drum loop, then shut down. -dr ___ 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 Thu, Feb 24, 2011 at 11:46 AM, Fons Adriaensen wrote: > On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote: > >> what you don't know (because you're not on IRC) is the question of >> N-point editing comes up a lot. i (and others) have argued (in my >> opinion quite successfully) that four point editing is a relic of an >> older workflow. others who have used 2, 3 and 4 point editing a lot on >> other systems have argued back. nobody has been persuaded to change >> their minds, and clearly nobody with the strong feelings in favor of >> it has been motivated thus far to implement it. > > Then tell me how to do the following: the position that i take with N-point editing is not that there is some other way to do "the following". There isn't. its that the way of approaching the task that leads to needing to do "the following" is rooted in an older way of thinking about the overall workflow. anyway, i've been through this debate at least 4 times in the last 2 years. i didn't persuade people who feel that its critical, and they didn't persuade me. status quo. > I don't have the time to hang out in chat room all day. Fortunately i didn't say that. but i will say this. i could have had this conversation with you on IRC in about 50% of the time it takes via email. IRC is one of the channels i meant. but what i meant much more was a reference to those people who, either via IRC, email or the bug tracker, get involved in an issue or feature and move it forward by (a) creating the "loop" (b) staying in the "loop". there are many bugs in ardour that i haven't fixed because i don't personally see them as big issues and because nobody has convinced me otherwise. it doesn't mean i'm right, but it does mean that if i (or someone else) is going to switch focus to feature X or bug Y, even though i (or someone else) isn't that motivated to do so, someone has to play advocate for the role. and its not an advocate in a sea of silence. there are long lists of bugs and long lists of cool features that we *want* to work on, at all times. for something to rise up above that particular ocean of noise does, unfortunately, sometimes require a bit of advocacy that goes beyond an email to a mailing list describing a problem. > I'm generally not interested in VBAP. I provides the worst surround > possible, even worse than most 5.1 panners. And in those rare cases where > it would be a good solution, I can derive the required signals from a more > universal encoding. well, panners in a3 are now plugins, of a fashion (they are a bit different from normal plugin APIs for a variety of reasons, primarily the fact that they never do in-place processing). its quite likely that at least the simplest of your ambi LADSPA plugins will show up in that fashion in the not too distant future, with a GUI very similar to the one in that screen shot. when i was in berlin attending "serious" concerts of electro-acoustic music, there seemed to be quite a range of opinion about ambisonics versus VBAP. although i tend to take your word for it on such matters, there were quite several smart people with years of experience in multi-speaker setups who had real issues with ambisonics and felt that VBAP was generally preferable. i don't want to make people choose. ___ 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 06:39 PM, Paul Davis wrote: well, panners in a3 are now plugins, of a fashion (they are a bit different from normal plugin APIs for a variety of reasons, primarily the fact that they never do in-place processing). its quite likely that at least the simplest of your ambi LADSPA plugins will show up in that fashion in the not too distant future, with a GUI very similar to the one in that screen shot. nice :) when i was in berlin attending "serious" concerts of electro-acoustic music, there seemed to be quite a range of opinion about ambisonics versus VBAP. although i tend to take your word for it on such matters, there were quite several smart people with years of experience in multi-speaker setups who had real issues with ambisonics and felt that VBAP was generally preferable. i don't want to make people choose. actually, i didn't like what i heard of vbap so far, but it does work as advertised, even under very adverse conditions. unless we have franz zotter's partial sphere magic firmly in place for all workflows, *and* there are kick-ass, fool-proof automatic ambisonic decoder generators for even the most pathological speaker layouts, vbap sure has its place. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Realtime threads and security
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote: > Hello Robin, > > Now, say I'm only focusing on playback now. Is there something wrong with > calling a blocking output API from a realtime thread as I ask below? > mmh. it depends on how the blocking is done. If it is a spin-lock it will consume CPU and block other processes which are running at lower priority in the meantime (but only up to sched_rt_runtime_us per second. Other processes won't starve). Is there a poll (or select) function available as part of the libaudio API? If the i/o block waits for a signal (e.g. IRQ), it will work just fine. >>> On Android, the closest that one can get to hardware in a more or less >>> portable >>> way is libaudio [1]. It's Android's audio HAL. This API exposes blocking >>> read() >>> and write() calls, with fixed buffer sizes (input and output buffer sizes >>> generally do not match, but that's another problem). >>> >>> So, this may be a silly/newbie question, but can one access this blocking >>> API >>> from a realtime thread? What will happen when it blocks? How does the >>> read/write >>> period relate to sched_rt_period_us? >>> >>> [1] http://source.android.com/porting/audio.html > > -- > Olivier ___ 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 Thursday 24 February 2011 18:09:19 David Robillard wrote: > To resolve this situation, we now have an exciting new Clippy inspired > assistant that hops around your screen begging you to add MIDI tracks > constantly. Will you call it ardourino? > If, after 20 minutes, you have still not created a MIDI track, Ardour > will overwrite every .waf file found in your home directory with a 4/4 > electronic kick drum loop, then shut down. You couldn't get the rights to use the amen-break for this? Have (much!) fun, Arnold signature.asc Description: This is a digitally signed message part. ___ 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 Thu, Feb 24, 2011 at 1:35 PM, Arnold Krille > You couldn't get the rights to use the amen-break for this? dude we don't use no breaks unless its "when the levee breaks", is that clear? problem is, jimmy and the boys in zep wouldn't clear the sample for us, so ... we're using a break from barry manilow's "copacabana". its all good. ___ 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
The amen break has no rights attached to it. It was a gift from the gods. Now whether or not those gods love or hate us is another matter... Michael - Original Message From: Arnold Krille To: linux-audio-dev@lists.linuxaudio.org Sent: Thu, February 24, 2011 12:35:39 PM Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb On Thursday 24 February 2011 18:09:19 David Robillard wrote: > To resolve this situation, we now have an exciting new Clippy inspired > assistant that hops around your screen begging you to add MIDI tracks > constantly. Will you call it ardourino? > If, after 20 minutes, you have still not created a MIDI track, Ardour > will overwrite every .waf file found in your home directory with a 4/4 > electronic kick drum loop, then shut down. You couldn't get the rights to use the amen-break for this? Have (much!) fun, Arnold ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Realtime threads and security
On 02/24/2011 07:01 PM, Robin Gareus wrote: > On 02/24/2011 03:59 PM, Olivier Guilyardi wrote: >> Hello Robin, >> >> Now, say I'm only focusing on playback now. Is there something wrong with >> calling a blocking output API from a realtime thread as I ask below? >> > > mmh. it depends on how the blocking is done. If it is a spin-lock it > will consume CPU and block other processes which are running at lower > priority in the meantime (but only up to sched_rt_runtime_us per second. > Other processes won't starve). Is there a poll (or select) function > available as part of the libaudio API? I don't think there are spin locks, which would say loop until some data becomes available, etc.. The libaudio implementation is provided by the device and/or the harware platform (main chip) manufacturer(s), so it's rather opaque. Some of these implementations are open source (http://android.git.kernel.org/), but they can differ a lot. But to prevent problem in case some libaudio implementations use a spin lock, then the audio server, audioflinger, could have limited realtime runtime, with sched_rt_runtime_us, as you mention (at first I was only thinking about this for the audio clients, not the server). I don't know about a select function exposed by libaudio. There are only blocking read() and write() functions AFAIK. > If the i/o block waits for a signal (e.g. IRQ), it will work just fine. That sounds good. In the implementations that I saw so far, when it's not ALSA, it seems to be some kind of OSS file-based interface. So I think that's quite safe to assume that read/write operation are backed by an interrupt. The one catch is that in all libaudio implementations that I saw, some mutexes get locked in both read() and write(). Is this a problem? I just looked into JACK1, and I see some pthread mutex being locked in oss_driver_read(), in drivers/oss/oss_driver.c. What happens in case of a mutex lock? Is there a context switch? -- Olivier ___ 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 Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard wrote: > The amen break has no rights attached to it. It was a gift from the gods. > Now > whether or not those gods love or hate us is another matter... > As far as I know the Winstons own the copyright (well... used to anyway, it might have expired) but they never chased anyone about lifting the drums... For an informative youtube browse there's a nice video on the start of sampling, dnb, etc: http://www.youtube.com/watch?v=5SaFTm2bcac Cheers, -Harry ___ 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
Heh, yeah, I know. I was more commenting on how every DJ on the planet has treated that sample. :) Michael From: Harry Van Haaren To: Michael Bechard Cc: Arnold Krille ; linux-audio-dev@lists.linuxaudio.org Sent: Thu, February 24, 2011 2:11:20 PM Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb On Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard wrote: The amen break has no rights attached to it. It was a gift from the gods. Now >whether or not those gods love or hate us is another matter... > As far as I know the Winstons own the copyright (well... used to anyway, it might have expired) but they never chased anyone about lifting the drums... For an informative youtube browse there's a nice video on the start of sampling, dnb, etc: http://www.youtube.com/watch?v=5SaFTm2bcac Cheers, -Harry ___ 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 Thursday 24 February 2011 12:09:19 David Robillard wrote: > This is, of course, a big problem in terms of our greater mission > to provide software that caters to the needs of precisely nobody while > irritating everybody else. > > To resolve this situation, we now have an exciting new Clippy inspired > assistant that hops around your screen begging you to add MIDI tracks > constantly. > > If, after 20 minutes, you have still not created a MIDI track, Ardour > will overwrite every .waf file found in your home directory with a 4/4 > electronic kick drum loop, then shut down. > > -dr Dude! This is just what I have been wanting but am too much of a newb to have even thought of undertaking such a complex project on my own! Hence my starting my soundwall project which I newbily thought was going to be a simple little app. I have some code inspired by some "anon" silence that could perhaps be included in this project. wwnnsnmsnm. cage-ily, drew ___ 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 Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote: > the position that i take with N-point editing is not that there is > some other way to do "the following". There isn't. its that the way of > approaching the task that leads to needing to do "the following" is > rooted in an older way of thinking about the overall workflow. The only conclusion I can arrive at from this, and despite lots of effort to avoid it, is that you don't have a clue as to what is involved in editing e.g. classic music recordings. Ciao, -- FA ___ 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 Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen wrote: > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote: > >> the position that i take with N-point editing is not that there is >> some other way to do "the following". There isn't. its that the way of >> approaching the task that leads to needing to do "the following" is >> rooted in an older way of thinking about the overall workflow. > > The only conclusion I can arrive at from this, and despite lots > of effort to avoid it, is that you don't have a clue as to what > is involved in editing e.g. classic music recordings. unfortunately, your conclusion would be wrong. ___ 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 2/24/11, Fons Adriaensen wrote: >> the position that i take with N-point editing is not that there is >> some other way to do "the following". There isn't. its that the way of >> approaching the task that leads to needing to do "the following" is >> rooted in an older way of thinking about the overall workflow. > > The only conclusion I can arrive at from this, and despite lots > of effort to avoid it, is that you don't have a clue as to what > is involved in editing e.g. classic music recordings. You know, I find this kind of attitude quite dangerous. JAMin developers not having clue, Ardour developers not having and clue, and then there's Fons in the shining armour never telling what is the right thing exactly, because "This is an error that any DSP student is allowed to make once". As much as I treasure your contribution (and I do), this is really disturbing. Especially since we are *sort of* community that is supposed to *sort of* share knowledge. Alexandre Prokoudine http://libregraphicsworld.org ___ 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 Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote: > You know, I find this kind of attitude quite dangerous. What attitude ? > JAMin developers not having clue, Didn't write that. > Ardour developers not having and clue About one very specfic issue. > "This is an error that any DSP student is allowed to make once". This is absolutely true for the one I referred to. > Especially since we are *sort of* community that is supposed > to *sort of* share knowledge. Indeed. And what knowledge have you been sharing lately ? -- FA ___ 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 Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote: > On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen wrote: > > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote: > > > >> the position that i take with N-point editing is not that there is > >> some other way to do "the following". There isn't. its that the way of > >> approaching the task that leads to needing to do "the following" is > >> rooted in an older way of thinking about the overall workflow. > > > > The only conclusion I can arrive at from this, and despite lots > > of effort to avoid it, is that you don't have a clue as to what > > is involved in editing e.g. classic music recordings. > > unfortunately, your conclusion would be wrong. Unfortunately, I don't think so. Or you have other reasons for not providing the sort of functionality that is needed. Without a single exception, everyone involved in this sort of work (classic or more generally, 'acoustic' music recording and editing) that I've shown Ardour to has said more or less the same thing: 1. it can't do it, or at best in a very clumsy way, and 2. it's a marvellous program otherwise, and it would probably take very little to solve its obvious problems. Not my words, but I do agree with them. -- FA ___ 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
You are full of even more shit than I am - can you just f-off and write your own DAW? Or at least go and write apps for an OS that has other developer lists. "we have to make sure that old fag [Fons] does disappear”. Jim Wong, president of IT products, Acer > Date: Thu, 24 Feb 2011 21:58:12 + > From: f...@linuxaudio.org > To: p...@linuxaudiosystems.com > CC: linux-audio-dev@lists.linuxaudio.org > Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb > > On Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote: > > > On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen > > wrote: > > > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote: > > > > > >> the position that i take with N-point editing is not that there is > > >> some other way to do "the following". There isn't. its that the way of > > >> approaching the task that leads to needing to do "the following" is > > >> rooted in an older way of thinking about the overall workflow. > > > > > > The only conclusion I can arrive at from this, and despite lots > > > of effort to avoid it, is that you don't have a clue as to what > > > is involved in editing e.g. classic music recordings. > > > > unfortunately, your conclusion would be wrong. > > Unfortunately, I don't think so. Or you have other reasons > for not providing the sort of functionality that is needed. > > Without a single exception, everyone involved in this sort of > work (classic or more generally, 'acoustic' music recording > and editing) that I've shown Ardour to has said more or less > the same thing: 1. it can't do it, or at best in a very clumsy > way, and 2. it's a marvellous program otherwise, and it would > probably take very little to solve its obvious problems. > > Not my words, but I do agree with them. > > -- > FA > > > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ 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 2/25/11, Fons Adriaensen wrote: >> You know, I find this kind of attitude quite dangerous. > > What attitude ? See below. >> JAMin developers not having clue, > > Didn't write that. *sigh* Really? "'True. After all those years none of the 'DSP experts' developing Jamin has noticed anything wrong when listening to it (it's quite obvious actually), let alone done a simple measurement that could have revealed this problem even before the first release." These were your words. So what I'm seeiing is that while JAMin guys write in their list that you, Fons, have interesting ideas about improvements in the backend, you, in return, write that utter bullshit. And then you pretend you never did that. And now I see this repeating with Ardour team. >> Especially since we are *sort of* community that is supposed >> to *sort of* share knowledge. > > Indeed. And what knowledge have you been sharing lately ? Lately I've been spreading tolerance and respect to fellow community members with a shovel. I'm pretty sure I can find some for you. Alexandre Prokoudine http://libregraphicsworld.org ___ 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 Fri, Feb 25, 2011 at 01:05:03AM +0300, Alexandre Prokoudine wrote: > "'True. After all those years none of the 'DSP experts' developing Jamin > has noticed anything wrong when listening to it (it's quite obvious > actually), let alone done a simple measurement that could have revealed > this problem even before the first release." Which is simply true. A simple measurement would have revealed that particular problem. Some critical listening would have revealed it as well. The term 'DSP experts' was first used not by me, but in an attempt to discredit what I wrote. So don't blame me for quoting it. > These were your words. And I'll repeat them any time you want. -- FA ___ 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 Thu, 2011-02-24 at 21:39 +, Fons Adriaensen wrote: > On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote: [...] > > "This is an error that any DSP student is allowed to make once". > > This is absolutely true for the one I referred to. As absolutely true as when I say the obviously terrible software architecture / design decisions that come out of certain DSP heads are... well, obvious terrible to anyone who actually knows what they are doing in that field? The trick is to know what you're good at, and shut up about the rest. -dr (Who couldn't - and thus won't try to - tell you the first thing about DSP, or classical music editing, or ...) ___ 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 Thu, Feb 24, 2011 at 06:47:10PM -0500, David Robillard wrote: > On Thu, 2011-02-24 at 21:39 +, Fons Adriaensen wrote: > > On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote: > [...] > > > "This is an error that any DSP student is allowed to make once". > > > > This is absolutely true for the one I referred to. > > As absolutely true as when I say the obviously terrible software > architecture / design decisions that come out of certain DSP heads > are... well, obvious terrible to anyone who actually knows what they are > doing in that field? That could very well be the case. With N >= 1000: There are some things I know about, N times more things I'm interested in, know a little about and want to learn more, and again N times more I don't know anything about. That's life. Now I'm here, I do have a question. And please just take it for what it is and don't look for anything behind it as there isn't anything. How did you arrive at the name 'ingen' ? This evening I happened to stumble on an episode of 'Midsommer Murders', a famous English detective TV series, on Youtube. Strangely enough it had Swedish (I think) subtitles. From which I learned that 'ingen' is Swedish for 'no, nobody, nothing' or similar... Again, that's not meant to be a comment on your program, just curious. Ciao, -- FA ___ 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 Fri, 2011-02-25 at 00:34 +, Fons Adriaensen wrote: > I learned that 'ingen' is Swedish for 'no, nobody, nothing' or > similar... Nobody it is. -- Brand new stockings http://mx44.linux.dk/notturno/brand_new_stockings.mp3 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
