Freewheeling is *so* unlike Live its hard to even link the two. Just for a start, Live is organized around a timeline, Freewheeling is not.

And, I don't think it's fair to call it McMusic - all I use Live for is an effects host for my guitar, because I like the builtin effects and it has by far the best interface of any audio app.

Anyway, having something like Ableton Live on Linux would be a great boon, it's the one single program that I still run Windows for. But IMHO recreating that from scratch as open source for Linux is a HUGE project, something of the order of Ardour's complexity.

SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue

On Thursday 06 April 2006 23:59, Lee Revell wrote: Indeed. I've been working on native AMD64 (Gentoo) for almost a year, and even though I spent most of my time hacking code for embedded 32 bit systems, I compile and test all code as native 64 bit as well. The only real problem I can remember having was with the heap relocation in EEL, where some messy pointer arithmetics is needed. Other than that, I'm using the exact same source code for 32 bit and 64 bit targets; no special cases or anything.

Basically, just don't assume that a pointer is 32 bits, and you're

fine. (That is, unless your programming style includes various inherently non-portable tricks. :-) Even in "naturally aligned" structs, you can usually get away with placing the pointers before any potentially smaller fields. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Thu, 2006-04-06 at 21:45 +0000, carmen wrote: Apps really don't have to be designed with 64 bit compatibility in mind - it should be rather simple to port them.

yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization.. i was able to whip up a LIVE-esque timeline GUI in an afternoon using the Tk wavesurfer library: http://whats-your.name/pr/seq.png but have yet to find the optimal backend. heres my investigations so far: PD and xsample~/dssi~: has the raw materials, but unfortunately doesnt work on amd64, and it its lack of subpatch polyphony means you would have to preallocate a set limit of active channels..and even a bit of disk access to load soundfiles is enough to get it kicked out of the jack graph due to its utter nonthreadedness.. SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module..

I can re-write Ableton Live with qt, and even make it fast in python (which escapes the linux-only concept, mind you :)) - that's not hard. What is hard is finding an engine that lets me focus on my GUI as opposed to the engine or *anything* related to communicating with the engine (besides the above calls, of course).

What are you working on, if I may pry?

As an added note to my previous comments, I really like the app interface that mpd uses. Writing ascii events using some spec or another to a file descriptor (socket in mpd's case) seems to be a terrific way to communicated with apps and libs. I run the svn pksampler like this: pksampler | pkaudiod I could just as easily have either use a socket or some other pipe, and this is easy to debug, script, profile, etc. On the client and server sides, I wrap my 10-minute rpc into an interface with generic calls. Everything having to do with input (MIDI, OSC, whatever) happens in the app code. The interface functions resemble those of FMODEx's interface; add sample, connect to channel, set sample attrs, etc. As an interface designer, the first thing I look for on an engine's project site is some sort of asynchronous API - I should never concern myself with anything outside referencing the api from my app's one windowing thread. FMOD, gstreamer, and my dead pkaudio project do this very well. I don't ever want to worry about what thread it happens in, what threads it will affect, or what the performance effects of *making* the call will be (as opposed to residual effects).

although i agree that this is the right design for many classes of application design, i would like to see how you propose to tackle metering and waveform display (the two most difficult examples). ardour would be relatively easy to separate into interface+engine processes (as opposed to just a lib/lib-client separation) if it were not for these issues. moving waveform and metering data back and forth between two processes via a wire protocol is very expensive and inefficient. --p

Paul, Everyone, What kind of assumptions can we make about the performance of the various FIFO pipe/socket/whatever mechanisms on a POSIX machine? This is by no means my area of expertise, but I currently hold the assumption that a POSIX machine should provide FIFO pipe-ish things that are *very* fast, considering they dont live in a local context. If native FIFO I/O mechanisms are not fast enough for, say, spewing 1/256th of a 10-20 second wave form's data to some app, isn't there something wrong? What metrics do you keep on the tip of your tongue after working with ardour and jack?

in yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization..

SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module..

Dave Robillard wrote: I also have a Q module for gstreamer on my TODO list (more geared towards video playback and editing, though). Has anyone tried gstreamer lately? Is it usable? Does the API still change a lot?

-- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

On Sat, 2006-04-08 at 03:04 +0000, carmen wrote: I found this very interesting: http://lurkertech.com/linuxvideoio.html It seems as if ALSA+JACK does exactly what this SGI engineer recommends ("just give me the data!") while gstreamer does the opposite...

yeah its not that complex. all you need is something that can play audio files realtime at varying pitches/speeds and apply FX chains, and a GUI to facilitate the arrangement and FX parameterization..

i was able to whip up a LIVE-esque timeline GUI in an afternoon using the Tk wavesurfer library: http://whats-your.name/pr/seq.png but have yet to find the optimal backend. heres my investigations so far: PD and xsample~/dssi~: has the raw materials, but unfortunately doesnt work on amd64, and it its lack of subpatch polyphony means you would have to preallocate a set limit of active channels..and even a bit of disk access to load soundfiles is enough to get it kicked out of the jack graph due to its utter nonthreadedness.. SC and Chuck: would likely work as well, but AFAIK neither one supports LADSPA or DSSI at the moment, SCLang definitely doesnt work on x86_64, and Chuck segfaulted as well but i'm guessing since its newer it was designed with 64bit compatibility and mind and the crash is some other issue SooperLooper + OSC-aware LADSPA Rack and Jack Patcher: seems like the jack graph would get crazy quick, but i will probably try this next, since the above options are out for me at the moment unless i setup a 32bit chroot, but maybe i will get good enough at C to be able to port sooperlooper to dssi~, since Om has eveyrhting else i'd need except a decent realtime-resampling audiofile module..

Lee Revell wrote: He must be a great hacker. :) But the engine is probably only a small part of the program. Getting the UI right is an entirely different issue.

On Thu, 2006-04-06 at 04:14 -0800, Patrick Stinson wrote: I think FreeWheeling might be the closest thing to Live that exists for Linux, have you looked at it? Lee

GDAM also has seamless queueing of upcoming tracks, numerous builtin effects and LADSPA and JACK support. You

Sorry, no release since then. I'm 90% certain that full JACK support is in CVS already, if not then it'll be in within a week as i'm planning a big cvs commit binge (purge?) of the last month's developments. Unfortunately I have no plans to release but do plan to keep CVS compileable and up to date. Simply can't be done given my schedule.

On Thu, Apr 06, 2006 at 04:14:32AM -0800, Patrick Stinson wrote: Everytime this comes up, i hesitantly recommend GDAM. Its an 8 year old C and glib project, a server/client music engine with various music interfaces on top. Its core goal was DJ mixing, back when there were few software dj apps available. The design for this was not at all "mimic a turntable or cd deck's interface" but rather "digital music files, each with one or more areas with regular rhythm, combined and symchronized in different ways". So there are server-side, sample-accurate synch functions based on defining tempo-and-downbeat for two tracks and commanding one to beatmatch to the other. It will even walk the audio tree and take filters which change tempo, resample, or add latency into account. It is truly sample accurate, you can play two copies of a song, invert one, beatmatch, and get silence. GDAM also has seamless queueing of upcoming tracks, numerous builtin effects and LADSPA and JACK support. You could implement the GDAM protocol yourself in any language, or program against the "client" library which handles the protocol, or program against the "model" library where a number of higher level client-side concepts (turntables, sequencers etc) are implemented. Also a GTK-based GUI library is available with pixmap-based widgets. Why the hesitance? I can't promise any time at all to explain or help. Development of GDAM has been ongoing but i haven't made a release in years, and the documentation is quite old, and doesn't cover developer topics. GDAM server audio engine really should be able to handle nearly anything you can dream up, its just a matter of all the organization and interface work. I was close to doing a live-alike myself (and have a half-finished attempt at a matrix-style loop mixing skin in CVS). If you search for GDAM or ableton in the list archives you'll find some other responses with more details. http://gdam.ffem.org/ -geoff

Il giorno lun, 10/04/2006 alle 11.22 -0800, Patrick Stinson ha scritto: GDAM needs GTK+ 1.2, not the more recent GTK+ 2.0. Even the non-gui server code needs GTK (the object system was split from GTK into GLib in GTK 2.0)