On Thu, Jun 10, 2004 at 10:17:52PM +0100, Steve Harris wrote: ok, tell us what you were actually trying to acheive by this and i'll tell you how you can do it on Doze. Obviously the solution on another platform is not going to involve jack:-) Anyway i agree, jack has great potential, and is probably the no.1 acheivement that has come out of linux audio. i dont mean to be aggressive, i'm just really intrigued to know how people get any music done. There is never any talk on this list or LAU about real software usage or workflows etc. for most people its not enough just to be able to do something, it has to be doable without impacting productivity or creativity. my personal experience is this: Music production is now an integrated process where the synthesis, composition, programming, recording, arrangement, and mixing of music overlap and everything is editable at all stages. I guess i'm biased by my own desires and studio experiences, but i do beleive this is what the majority of people want. such a system is not acheivable by bedroom hackers, it requires some cooperation and organisation. Currently all we have are the supporting peripherals (synths, editors, fx). is there really noone here who is seriously interested in this? -- Tim Orford

On Fri, Jun 11, 2004 at 10:17:24AM +0100, Steve Harris wrote: this should be a simple automation or patch-loading thing. moreover, iirc, the design of jackd makes no consideration for 'live' routing changes. At least on my system, changing the graph results in an xrun. cheers -- Tim Orford

[Paul Davis] it can be done no matter the weight of the resources involved if the resource handling (allocation/release) is, as you indicate, completely decoupled from the realtime thread. admittedly, the approach is tough to implement -- i'm doing it in a one-process context, and it works; but within the multi-process context that is jack i can understand your reluctance to do it. tim

On Fri, Jun 11, 2004 at 08:37:09AM -0400, Paul Davis wrote: It can be done, but as you say it's not simple and requires very careful design. The 'heavy state' is AFAICS not the real problem. Heavy things can be put in place before the actual graph reordering is done or removed after. This does not need to be done in the RT thread. There seems to be a deeper problem: the existence of non-RT callbacks together with the fact that jackd knowns only about one thread in the client. This means that jackd has to wake up the client's RT audio thread in order to do a callback. While the callback runs, the audio thread is not available to do the normal process callback, since it's not waiting for the trigger. One solution would be to require that the RT thread immediately hand over the callback to a lower priority thread, but this means we have no real callbacks, but notification events. Not entirely true. If the connect/disconnect calls are allowed to be blocking (which of course means they can't be used from the RT thread), OR if they are allowed to be asynchronous (which means they just pass on a request that will be acted upon some time after they return) then it is perfectly possible even if some heavy objects need to be handled. I wrote a JACK-like system doing exactly that about six years ago. 'No hickups' during connections was a requirement, and I had to prove compliance. -- FA

On Fri, 2004-06-11 at 03:42, Tim Orford wrote: Most of that talk is on ardour-dev. Ask Ron Parker about workflow. He's got his setup pretty much under control (with the occasional bug of course :) I am recording/mixing originals alone and with my band(s) using Ardour, effects from LADSPA (SWH and TAP for the most part), mastering with JAMin, final clip with Audacity, and burning CDs with XCDRoast. I don't do MIDI or synths, I use guitars, harmonicas, bass, percussion, real drums or loops, bass, and keys when I can find someone that will lay down tracks ;-) I don't know what the state of the MIDI apps is at this point but Ardour and JAMin are usable. Also, being one of those bedroom hackers, I just want to point out that I've been a professional programmer for 26 years. I've done mostly scientific graphical editing and data structures programming, but also real-time data acquisition. I've worked on just about every OS known to man (including the dreaded OS360). Why is there always this assumption that the only people who work on open source projects are kids in college and weekend warriors? The things that I don't understand (like DSP :) are covered by other "bedroom hackers" like Paul Davis, Steve Harris, Jack O'Quin, Taybin Rutkin, Jesse Chappell, Andrew Morton, Linus Torvalds... ;-) Jan

On Fri, 2004-06-11 at 08:39, Steve Harris wrote: My wife agrees. She says it started right around 40. Go figure ;-) Jan

On Fri, Jun 11, 2004 at 07:15:24AM -0500, Jan Depner wrote: yeh you guys are lucky, not only do you get to work with real instruments but your software requirements are much more easily satisfied:-) these guys may be "bedroom hackers", but they are not 'merely' such:-) regards -- Tim Orford

i have a very hard rule against hacking in the bedroom. i have broken it once and will never do it again. "garage hackers", "living room hackers" and right now "on the bar in the kitchen hackers" .. sure, but never, ever a bedroom hacker. --p

all work and no play already makes me a bit of a dull boy. mixing work and play would make things even worse :) more seriously, its necessary to be able to escape from programming. if not the bedroom, then where? --p

Tim Hockin <thockin(a)hockin.org> writes: That only wakes you up when the build succeeds. I'd rather sleep late in that case, and only wake up if the build fails... $ make || echo ^G^G # ;-) On a more serious note, does it count if it used to be a bedroom before I converted it into a home studio? :-) -- joq

On Fri, Jun 11, 2004 at 01:21:51PM -0400, Paul Davis wrote: Point taken. Some days I'm beyond dull, I'm a bit nuts. I use the living room for that. Very relaxing when nobody's home :-) -- Paul Winkler http://www.slinkp.com