Den Thursday 27 August 2009 20.09.08 skrev Atte Andre Jensen: Hi, It can be worthwhile to have peek at winhq. Click on the versionnumber and see if the problems might have a work around. Ableton 7.0.3 seems to be working. http://appdb.winehq.org/objectManager.php?sClass=application&iId=2113 cheers /bengan

On Thu, Aug 27, 2009 at 12:45 PM, Paul Davis<paul(a)linuxaudiosystems.com> wrote: I'm convinced that, if anyone on the face of the planet can pull off writing an AL-alike application, it would be you, Paul. :) hint, hint (as if you don't have enough to do already!) -- Josh Lawrence http://www.hardbop200.com

On Thu, Aug 27, 2009 at 2:42 PM, Ray Rashif<schivmeister(a)gmail.com> wrote: I understand (most of) what is needed for "elastic time" in ardour. However, when I saw a PT demo of this feature, what shocked me deeply was the GUI elements of it. What digi did with it is nothing short of amazing on the GUI side. Ardour has a significant benefit over PT in that from its inception, it has always been "live" - you have always been able to edit while playing and have things take effect almost immediately. However, the GUI stuff in PT's elastic implementation is HUGE, probably much more difficult than the backend implementation by at least a factor of 4.

On 08/28/2009 06:20 PM, Grammostola Rosea wrote: I have used Ardour as a live playback engine and it is very useful. Realtime multichannel, streaming from disk, onboard and offboard fx processing. I would love to have the hardware to work with it as a complete live mixing solution. Patrick Shirkey Boost Hardware Ltd

On Sun, Aug 30, 2009 at 4:09 PM, Ray Rashif<schivmeister(a)gmail.com> wrote: more than this. AL was written in part based on its initial authors' experiences with other DAWs and represented an attempt to create an all-in-one package that would meet what they believed were the emerging workflow demands of "modern artists". AL is specifically NOT conceived by its creators as something to supplement the use of other DAWs. Whatever its flaws may (or may not) be, AL is intended to do everything you need to do when creating music (though admittedly, it has some stylistic biases that make it less suitable for some kinds of music production). --p

On 08/31/2009 04:35 PM, Atte Andre Jensen wrote: I think that the idea is not to hack things but to integrate the expected functionality. the main problem is that AL has established an interface standard and although many people have found they can do just as much with jack and their favourite apps many more would rather see a more unified approach. I personally feel that hydrogen in combination with one of the file based loopers will be a very powerful combination with a few relatively easy extensions to the existing Hydrogen interface. I am also now very interested in what Niklas is working on. Patrick Shirkey Boost Hardware Ltd

Josh Lawrence wrote: I'm not Paul, but I'd be willing to participate in such a project. Actually this (a live daw) might be the largest blind angle in linux audio, and as others I survive with good-enough home brewed stuff (mine is done in chuck, I imagine most use pd or supercollider). Mine is working ok, getting more and more polished, but still only does what I need the most (although some of that is outside the scope of live, like algorithmic improvisations guided by user input). If I had a (much) better performing backend and a drag/drop + midi-leaning gui, I'd be most of the way for my needs. If my effords were put into a common codebase where others implemented *their* needs, I wonder how far we'd be :-) Any thought? Any almost-there project that we could/should convince to take a live turn and throw our efforts into? Maybe if the community could work out a proposed roadmap, we could look at it together, see who could work on what and if the required skills were within reach. NB: I never used ableton live, but saw it, know others that use it, and it *seems* to be a time saver for what I do live. NB2: I'm not gonna start the above mentioned project myself. There are too many areas (esp gui programming) that I know nothing about. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Gabriel M. Beddingfield wrote: :-) Could you elaborate? What similarities, what's missing (just the big picture), it's been a while since a glanced at hydrogen. Agreed. Just thinking about doing a high performance, jack enabled, realtime friendly audio engine makes me tired (maybe because I wouldn't know the first think in doing it right). An other way could be using an existing backend, csound comes to mind. I only played a bit with it's API, not sure what can be achieved through this. Blue works with the csound API, and also needs "just a few things" to be heading in this direction. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

On Thu, 27 Aug 2009, Atte Andre Jensen wrote: The main feature of AL is the scenes and loop-based composition, right? This is essentially a specialized sequencer/sampler. And hydrogen is a sequencer/sampler. Further, Hydrogen is based on the idea of have several patterns (like a loop) that you set up. Then the song is composed in a sort of paint-by-numbers fashion. This is a lot like AL's scenes. Hydrogen also has some DAW-like features, including some primative mixing and FX. Hydrogen lacks any code for looping or beat slicing. Also, the audio internals are a little ugly IMHO -- but I've been working to improve that. When I'm done, I expect the backend to be *very* DAW-like. OTOH, a better starting point *might* be something like sooperlooper. Heh. That stuff that gets my motor running these days. :-) Peace, Gabriel

On Friday 28 August 2009 05:39:15 Patrick Shirkey wrote: Hi, i'm happy to state that hydrogen IS able to play multiple patterns at the same time. In hydrogen 0.9.4 we call that "stacked pattern mode". At the moment you have to select the patterns with your mouse. It's not implemented to select patterns via midi, but if you really want it, open a ticket[1] and i'm going to look at it when i've got time to.. - Sebastian [1]: http://www.assembla.com/spaces/hydrogen/tickets

On Fri, 28 Aug 2009, Patrick Shirkey wrote: 1. Start hydrogen (current SVN or 0.9.4-RC2) 2. Put it in pattern mode. Enable looping. 3. Edit Patterns 1, 2, and 3. 4. At the top of the patterns list, there's a button with a single line. The flyover will say "stacked pattern mode." Click it so that there are two lines, thus entering stacked pattern mode. You'll notice a little arrow beside Pattern 1. 5. Press start. Pattern 1 will start to loop. 6. While Pattern 1 is playing, Ctrl+LMB Pattern 2. When Pattern 1 loops, it will be *with* Pattern 2. 7. Now Ctrl+LMB Pattern 3. At the end of the current cycle, it will also start playing. 8. Now Ctrl+LMB Pattern 2. At the end of the current cycle, Pattern 2 will *stop* playing. HTH, Gabriel

On Fri, 28 Aug 2009, Patrick Shirkey wrote: No prob. I need to get it into the manual........ *blush* If patterns have different lengths, I *think* it will loop after the longest pattern has finished. Nevertheless, there is no checking to see that patterns have the same length. So, yes... H2 supports multiple time signatures. Peace, Gabriel

On 08/28/2009 09:36 PM, drew Roberts wrote: In this case I am referring to a grid of buttons that can be used to trigger the various patterns. The is seperate from the pattern sequencing grid. The buttons would be larger and shinier and the column would be roughly 4 - 10 buttons wide. On each button the pattern name would be displayed. When pressing the button it would trigger the pattern on/off. It's actually not needed in order to get the multiple patterns playing at one time as Gabriel explains in his last post. However it is what AL users would be used to. Patrick Shirkey Boost Hardware Ltd

Hi Jesse, On Mon, 31 Aug 2009, Jesse Chappell wrote: Would you mind expanding on this? Why would it not be a good starting point? Why are you wanting to re-implement it? Also, FWIW, I've considered that another application might interface with the sooperlooper server rather than forking the project. Thanks, Gabriel

Josh Lawrence wrote: Agreed. Moneys a good thing. I've never been involved in a major project, but things like documentation, wiki-cleaning, testing, roadmaps might be areas where non-coders could help out. -- Atte http://atte.dk http://modlys.dk http://virb.com/atte

Atte Andre Jensen schrieb: I am currently writing something comparable for my master-thesis. The thesis itself is about collaborative applications (using multitouch-tech.), their design and change of paradigms in current interface-design principles. As example/proof of some concepts, I am writing a sequencer that's geared towards live-sequencing. It incorporates a lot of interesting concepts for music notation/sequencing; in a way it is like ableton live insofar that it supports outlining and playing with musical ideas independent from a main-arrangement - just like live does with the triggering clips in slots in the grid-based view. It is more abstract and general/powerful, though. The sequencer itself outputs OSC and primarily drives supercollider but you can use anything else on the synthesizer-side of course (like processing to sequence visuals (according to the music)). The application will be ready around december (deadline for the thesis). The code base is fairly abstract, so more common devices for input/controling like mice/keyboard/midi-controlls or any other TUIO-stuff can be supported. I am planning to add some functionalities that increase the workflow on the usual (single-user input) computer-setup afterwards. I've been producing music commercially for some years now mainly using ableton live and a sequencer with a similar workflow is what kept me from using linux or F/OSS as main production tools; so I expect the final application to be basic, but quite usable :) As a side note, keep an eye on the awesome Renoise, since they are adding more and more live-features (midi-control/learning for device-control (fx/synth) etc is already quite good); patterns can be triggered live but currently not via midi. niklas

Atte Andre Jensen schrieb: sure. But keep in mind that the whole app is rather radical conceptually, although you can sequence similarily to the usual DAW concepts. The whole codebase is geared towards extendability for new features, so that other ppl can add more sophisticated functionality later on (new datatypes that can be sequenced, different editing-methods, other synths and whatnot). The src is already GPL licensed. A public release will need some polishing of the code though due to the short time-frame I am working in which forces me to sacrifice some code-quality. The major stopper for many devs will be the fact that I am developing using JAVA (and a little of C for clocking, etc). For a community project this choice makes sense though (excellent out-of-the-box dev tools, clarity of code, easy cross-platform development...). yeah. for me the show-stopper is the lack of a (good) pattern sequencer and arbitrary pattern lenghts as well as unlimited f/x rows.

Josh Lawrence wrote: I'm developing an Ableton-like midi/audio -sequencer. It's a pet project of me for upgrading my liveset which uses my old MSDOS midi sequencer. That sequencer is much like an Ableton Live without the audio, loading patterns/songs to the background from disk is done while already playing a song. And switching between songs is done on a 'track by track' or 'all tracks at once'. This works just like the sessiongrid in ableton only dynamically from disk. I needed to get rid of my old, big and slow dinosaur Yamaha A3000 sampler and wanted to put sampling inside the sequencer but staying on the MSDOS playform was just impossible... The application is developed in FreePascal/Lazarus-IDE with api bindings to Jack/Ladspa/libSndFile/libSoundTouch. As developing with Lazarus is multi -platform/toolkit, it would be quite easy just to crosscompile for Linux/Mac OSX/Windows (even across gui toolkits like Gtk1, Gtk2, Qt, Win32). The reason for developing in FreePascal instead of C++ is my background in Pascal programming going back about 18 years. Using Lazarus as RAD tool is also both easy and fast. The only big question for me is what licence to use: GPL and maybe acquire eternal fame in the opensource community. :) or Release it closedsource for about 50 euro just like Renoise and Energy-XT. I do not want to release it (except maybe some beta versions/screenshots) until it does most of the things I want it to do (which will take about a year). That would be v1.0 About the application itself: a very early alpha screenshot: http://www.sensoryoverload.nl/images/HybridSequencer.png It is different to Live in that instruments and drumkits are not hosted inside a track but globally managed by the application as one big processing bank. A pattern can contain a sample (drumloops etc) and MIDI data. Midi is sent to the global sampler or external instrument and returned to the sending track. This would for example preserve memory when you just want to use a few drumsounds instead of loading complete drumkits. MIDI data can also be used to trigger at transients of drumloop in the same pattern. Also when you want to play the same drumkit at the same time in two or more tracks, there is almost no extra memory footprint. This makes dragging patterns across tracks and combining different drumloops, instruments and plugins far easier to manage than Live. Loading and combining livesets/songs/patterns from disk while already playing would be possible, even staying in sync. Making the audio-thread non-blocking from begin-to-end is a high priority (also the most difficult). There are dozens of other ideas to implement os this is not a complete description of the thing. Roadmap (main features) ---------------------------------------------------------------------------- PRE v1.0 - Sample Warping with WarpMarkers (just like Live 8 with visually stretching sampledata) using libSoundTouch 100%, done (needs some gui-love though) - Session grid 50% dragging tracks works, dragging(moving form track to track) patterns inside the grid and dragging livesets/patterns/samples from disk needs to be done. - Midi pattern editor 30%, creating, destroying, moving notes and scrolling, zooming implemented. Maybe layer on top of sampledata - Global sampler 25%, Framework is in place playing dry unprocessed samples, "just" needs the dsp part for filters, envelopes, fx and such. - Midi controller mapping 10%, started on framework - Ladspa track plugins 30%, api bindings completed, basic framework started - Persistent unlimited undo/redo framework 75%, only 'recovery from crash' needs to be implemented - Loading/Saving of patterns/livesets 25% POST v1.0 - Integrate controls (LASH) to connect to Ardour as main DAW - LV2 support - Develop a multiband WSOLA timestretching algorithm with transient handling for higher quality. - Mac OSX version cheers, Robbert Latumahina

Atte Andre Jensen wrote: Thanks for your input! As this is my pet project I do want to keep complete control over development and also keeping the code as compact as possible. Keeping it closed source would secure that for me, that's really the main reason. The other (not that important) reason is that I code this in my lunchbreak (and when bored and nobody is looking) via remotedesktop. And putting in more hours is not really possible except working less and get paid for the software. If there's a opensource way around it I would do it. Still, I have given myself a year to get to a workable version and in the mean time I will decide how to release it. cheers, Robbert

Grammostola Rosea wrote: AFAIK all used libraries like libJack, ladspa, soundtouch and libsndfile are LGPL. So that would not be a problem closed or open -source. About the licensing.. I'm very flexible and this discussion does tend to bend my direction to opensource, so by tomorrow.... Robbert