Re: [LAD] Non Session Management
On Tue, Mar 27, 2012 at 07:41:27PM +, Fons Adriaensen wrote: On Mon, Mar 26, 2012 at 05:15:09PM -0700, J. Liles wrote: Fons, I'd like to hear more about this use case. Currently one of the strong points of NSM is that applications with heavy state (e.g. large audio files) know *exactly* where to put the state at the time they join the session. This eliminates the need for undesirable hacks with just storing a link to the heavy state (as was generally required with LASH). I felt like this was one of the primary requirements of Non-DAW which was not addressed by other session managers. But as far as sharing heavy state between multiple clients in a session, I have not considered the issue. It is certainly possible to permit something like that, and even as it is right now two clients could work something out peer-to-peer using the NSM server's 'broadcast' capability. If several different sessions need to share the same data, then I would say that it's reasonable just to have it stored outside of the session root, preferrably symlinked from within the session so that it could be picked up by a simple archiving process. You may have misread what I wrote, it's not about data shared between clients in a single session (but that is an interesting twist that I havent' considered so far). It's a about essentially read-only and possibly huge data sets shared between sessions. Given a multitrack recording, I may be required to make a 3rd order Ambisonic mix originally, another for some discrete speaker set used at a concert some months later, and a Wave Field Synthesis one at any time. They all use the same recorded and edited tracks, but the tools and methods used are completely different in each case, and I would really not want to combine them into a single session. If only because someone using any of these forms should not be required to have the tools for all the other ones. Nor would I want the the shared data to be duplicated - not only because it's a wast of disk space, but also because it may be reviewed and modified as well (e.g. correcting bad edits) and such changes should be picked up by all sessions using the data. So the shared data would not be read-only after all... Isn't this a little bit dangerous? I can see this could work with certain kinds of apps that are non-destructive. But how do you know that doing edits to the data in one session doesn't make the other invalid. In other words, how can you control such a thing without duplicating data? lieven ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] HDSP 9652 and Behringer ADA8000
Hi, im running it for a few year... works perfect bye Ck On 28.03.2012 01:44, Phil T wrote: Hi Everyone Im would like to experiment using microphone arrays ( 24 channels ) and I am just wondering if it is possible for me to use 3 units of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools run only with ALSA supported devices and I checked through ALSA website, the HDSP 9652 seemed to be OK. Im just wondering if the set-up I mentioned is possible ? Will there be any issue at all if i use the ADA8000 as far as ALSA is concerned ? Thank you very much, I really would appreciate any suggestions or comments. Thank you Phil ___ 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] Non Session Management
Am 28. März 2012 05:42 schrieb David Robillard d...@drobilla.net: On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote: I am having a hard time imagining anything *less* likely to be adopted than trying to cram a *database* down everyone's throats to save some files! ;) With database here, actually, I'm refering to a more or less simple text format. for example, recently I stumbled about: GNU recutils (readable, but it is slow) No session manager that forces everyone to use some database would ever fly. This is obvious. It doesn't force the clients to use a db. The SM would have a text-db and simply communicated with the clients, to find out their files-in-use. - having symlinks leaves the user with the question how to reliably copy a directory, without messing up everything (dereference yes/no, follow links yes/no ...), something that is critical to deside That is inherent to any solution with links to external resources. Links to external resources are a requirement. If you want to move a session, use a smart tool that can fix the links, or archive it. The point here is to make it as simple and as little fault-prone to the user as possible: A user should be able - with a single button-click (or cml) - to make a directory with all files belonging to a session, optionally either keeping references or creating copies of them (of Lfiles). Did you ever re-assign 200 symlinks ? Compare that with a simple search-and-replace in a textfile, with an editor of your choice. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: A second scenario The simple one (simple for the SM, not for the apps): - applications decide themself how to handle large-files - but still tell the SM about all files currently used, when the session is saved Files are files. Size does not have any impact on how any of this has to work (aside from the fact that files could possibly be very large meaning redundant copies are not acceptable). Trying to define a small file and large file category just makes everything more complicated for no particular reason. Why? What exactly is large? Just because a file is large doesn't mean I don't want it in a session. It is a requirement to be able to roll up a self-contained archive of a session *if* you want to. The reason is simple and important: Duplicating a session should be lightweight. Lfiles _belong_ to _one or many different_ sessions, but they would not be stored within the session folder. Instead, a cloned session would contain references to _the same_ Lfiles, as its original ! This means, no Lfiles are copied, just referenced, thus its a quick procedure. This is no problem, if applications are non-destructive: If the clone had to change a file, it would create a copy in the Lfiles directory and use this new reference. For destructive apps, this woulde not work obviously and the SM would have to duplicate their files in the Lfiles directory too. What is a large-file ? (for a non-destructive app) Every file, that is not required to immediately become copied if a session has to be cloned. Every file, where a reference is enough in the first place. What is NO-large-file ? Data that is required to access large-files (references), or that is lightweight (~below 1MB) (some config-values), or has to be read by the SM to initialize the client. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM Why would the user care? (Lets assume I haven't use a certain machine for half a year...) For many reasons: - deleting - I would like to know, if I'm allowed to delete a certain file, thus it's important to know if it is still used by any session - destruction - I'm planning to use a destructive application an a file and would like to know, if this file is used by any session, where this modification would cause trouble - duplication and release - one may intend to export all files (maybe of a certain type) for a certain session and send them to a friend. - freeing disk space - I would like to remove all files not used (anymore) by any session (or by a _certain_ session). how else would I know ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
2012/3/28 Emanuel Rumpf xb...@web.de Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM Why would the user care? (Lets assume I haven't use a certain machine for half a year...) For many reasons: - deleting - I would like to know, if I'm allowed to delete a certain file, thus it's important to know if it is still used by any session - destruction - I'm planning to use a destructive application an a file and would like to know, if this file is used by any session, where this modification would cause trouble - duplication and release - one may intend to export all files (maybe of a certain type) for a certain session and send them to a friend. - freeing disk space - I would like to remove all files not used (anymore) by any session (or by a _certain_ session). how else would I know ? this all sounds really interesting, but IMHO these are all extras (that can introduce a lot of extra complications) if i can tell the SM where the session needs to be stored that's enough for me. i really dont care how the underlying files/dirs are organised all i care about is that i can save/restore a session. and if this comes at the price of HD space, so be it if i know where the sessions are stored it's easy enough to archive the complete dir and move it to a fileserver thijs -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- follow me on my Audio Linux blog http://audio-and-linux.blogspot.com/ ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] HDSP 9652 and Behringer ADA8000
Hi phil, i used different distros... at the moment im using linux mint 12 with rt patch, ubuntu studio 9.04 to 10.04 with lowlatency kernel. on any system the 9652 was running fine. if you just want to record stuff you dont need rt. only if you want to do processing of any kind, rt is needed. the 9632 has no expansion board, therefore it only has 16 in and 16out. the 9652 is the same card but with the expansion board, capable of 24 in/out. bye Ck On 28.03.2012 14:59, Phil T wrote: Hi Christoph, Thank you ! I am really new to hardware and stuff. I am just wondering what linux distro are you using ? Do you think ubuntu may suffice ? I have read some threads suggesting to manually compile a kernel enabling rt and Im just wondering if you have manually compiled a kernel in your case ? Lastly, in the RME homepage, it says that the HDSP 9652 can have up to 16 inputs. However if I am not mistaken, it also says it has 3 ADAT input so Im just wondering with 3 ADAT input, it could be possibly take in 24 inputs all in all. Thank you very much. Phil On Wed, Mar 28, 2012 at 6:35 PM, Christoph Kuhr christoph.k...@web.de mailto:christoph.k...@web.de wrote: Hi, im running it for a few year... works perfect bye Ck On 28.03.2012 01:44, Phil T wrote: Hi Everyone Im would like to experiment using microphone arrays ( 24 channels ) and I am just wondering if it is possible for me to use 3 units of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools run only with ALSA supported devices and I checked through ALSA website, the HDSP 9652 seemed to be OK. Im just wondering if the set-up I mentioned is possible ? Will there be any issue at all if i use the ADA8000 as far as ALSA is concerned ? Thank you very much, I really would appreciate any suggestions or comments. Thank you Phil ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org mailto: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 mailto: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] Non Session Management
On Wed, 28 Mar 2012 15:35:26 +0200 thijs van severen thijsvanseve...@gmail.com wrote: 2012/3/28 Emanuel Rumpf xb...@web.de Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM Why would the user care? (Lets assume I haven't use a certain machine for half a year...) For many reasons: - deleting - I would like to know, if I'm allowed to delete a certain file, thus it's important to know if it is still used by any session - destruction - I'm planning to use a destructive application an a file and would like to know, if this file is used by any session, where this modification would cause trouble - duplication and release - one may intend to export all files (maybe of a certain type) for a certain session and send them to a friend. - freeing disk space - I would like to remove all files not used (anymore) by any session (or by a _certain_ session). how else would I know ? this all sounds really interesting, but IMHO these are all extras (that can introduce a lot of extra complications) if i can tell the SM where the session needs to be stored that's enough for me. i really dont care how the underlying files/dirs are organised all i care about is that i can save/restore a session. and if this comes at the price of HD space, so be it if i know where the sessions are stored it's easy enough to archive the complete dir and move it to a fileserver if I may add my voice, from a very practical user point of view, I agree with thijs. The functionality Emanuel is proposing does sound very interesting, and it *would* be very nice to have, but if I had limited time to code (which I think is something to seriously take into account on open source projects) I would maybe reserve these things for future versions, focusing now on the more basic stuff. I.e. I would gladly give up some disk space, at least for the present, to have a solid, functional and wide adopted session manager (like Non seems to be, except for the last requirement). Of course those having recordings of several gigabytes won't agree with me, but again this is just my personal opinion. cheers, renato ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Wed, 2012-03-28 at 14:11 +0200, Emanuel Rumpf wrote: Am 28. März 2012 05:42 schrieb David Robillard d...@drobilla.net: On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote: I am having a hard time imagining anything *less* likely to be adopted than trying to cram a *database* down everyone's throats to save some files! ;) With database here, actually, I'm refering to a more or less simple text format. for example, recently I stumbled about: GNU recutils (readable, but it is slow) [...] Did you ever re-assign 200 symlinks ? Compare that with a simple search-and-replace in a textfile, with an editor of your choice. In addition to not being archivable by any archive tool, and not transparent to file system tools, anything but normal files means you don't have normal app state in the session anymore, but need some kind of mechanism to ask for every single file. This means loading code gets weird and depends on the session manager, and the app's session format also depends on whether or not it was saved with the session manager. Apps are not going to go for that, period. It should be obvious by now that a prerequisite for a session manager that is actually going to be adopted is it doesn't ram a bunch of annoyance down implementer's throats. Any such annoyance needs a very compelling argument to counteract that. I don't see one here. A sufficiently compelling argument would be something important that works that could not work without all the additional junk. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Wed, 2012-03-28 at 18:31 +0200, Renato wrote: On Wed, 28 Mar 2012 15:35:26 +0200 thijs van severen thijsvanseve...@gmail.com wrote: 2012/3/28 Emanuel Rumpf xb...@web.de Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM [...] if I may add my voice, from a very practical user point of view, I agree with thijs. The functionality Emanuel is proposing does sound very interesting, and it *would* be very nice to have The mentioned functionality does not depend on a centralized file store. That's the point I'm trying to make, it's not complexity that wins us a bunch of nice features, it's just complexity. At most what is required for some of them is the session manager know about registered /sessions/. This is a dramatically different thing than building a prison for all /files/. While not bulletproof (you could have sessions on a removable drive), it's not really a problem because it doesn't impose anything on apps. I.e. I would gladly give up some disk space, at least for the present, to have a solid, functional and wide adopted session manager (like Non seems to be, except for the last requirement). Of course those having recordings of several gigabytes won't agree with me, but again this is just my personal opinion. Lack of a centralized file store does not mean large files would be duplicated. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK session API in Perl, Python, Ruby, and Lua
On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote:
Am 21. März 2012 18:28 schrieb Joel Roth jo...@pobox.com:
https://github.com/navicore/Jacks
hm ...
The code uses a mutex_lock in the process callback:
_lock(_this_);
_this_-nframes = nframes;
_unlock(_this_);
From the doc of pthread_mutex_lock: If the mutex is already locked,
the calling thread blocks until the mutex becomes available.
A try-lock (pthread_mutex_trylock) may be less likely to disturb jacks
process flow.
--
E.R.
Hi folks. I'm the author, new to the list, new to audio, been on
vacation but back now and hoping to learn and contribute. Programming /
playing with jack has been fun!
Emanuel, thx for the suggestion. The job of that mutex is to block the
callback until the user code has run, _trylock wouldn't do that.
It is the same approach jack uses when you call jack_session_reply, an
event completion token pattern that runs this code from jack engine.c
code
static void
do_request (jack_engine_t *engine, jack_request_t *req, int *reply_fd)
{
/* The request_lock serializes internal requests (from any
* thread in the server) with external requests (always from the
* server thread).
*/
pthread_mutex_lock (engine-request_lock);
/code
I intend to change to _timed_lock for safety but the mutex is there to
serialize execution between the callback and the perl/python/ruby/lua
user code. Open to different designs but this one lets me expose the
Jack API to multiple languages with one swig.i file and lets the user
program in a synchronous style.
The overhead of the context switching and locks is unfortunate. Works
fine for me reimplementing the example-clients with 48000 sample rate
but I'm a n00b and don't know what real processing looks like.
Can anyone point me to a way to stress test? I'd like to know at what
point all the overhead of my approach plus the costs of the host lang
VMs breaks things.
Btw, I'm sure the main value of a pkg like this is the session api and
not the processing. If you don't open any ports it won't register the
process_cb callback with Jack and you won't have the processing costs.
Regarding the build/install, I intend to make the main build system
generate platform distribution-friendly installable dist files rather
than the ./configure stuff it uses now. CPAN-friendly, rubyrock,
luarock, etc...
Sorry for the long post
-Ed
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On Wed, 2012-03-28 at 10:35 -0700, Ed Sweeney wrote: On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote: [...] The code uses a mutex_lock in the process callback: _lock(_this_); _this_-nframes = nframes; _unlock(_this_); [...] Emanuel, thx for the suggestion. The job of that mutex is to block the callback until the user code has run, _trylock wouldn't do that. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On 03/28/12 10:45, David Robillard wrote: [...] Emanuel, thx for the suggestion. The job of that mutex is to block the callback until the user code has run, _trylock wouldn't do that. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. -dr gotcha, thanks david. looking at ringbuffer now. -- Ed Sweeney, http://www.onextent.com, Los Gatos CA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On Wed, 2012-03-28 at 10:47 -0700, Ed Sweeney wrote: On 03/28/12 10:45, David Robillard wrote: [...] Emanuel, thx for the suggestion. The job of that mutex is to block the callback until the user code has run, _trylock wouldn't do that. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. gotcha, thanks david. looking at ringbuffer now. You're welcome. The capture_client.c example in jack is sort of what you'd have to do, but only in one direction. Someone else may know of a more directly applicable example... (Though, personally I'd suggest using a semaphore if available instead of a mutex/cond pair; sem_post is the best way to signal from the audio thread and the signal will always get through unlike a trylock. Semaphores are awesome, it's really a shame that most portability libraries (and C++0x) don't include them...) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
Am 28. März 2012 19:35 schrieb Ed Sweeney e...@onextent.com: Hi folks. I'm the author, new to the list, new to audio, been on vacation but back now and hoping to learn and contribute. Programming / playing with jack has been fun! Emanuel, thx for the suggestion. The job of that mutex is to block the callback until the user code has run, _trylock wouldn't do that. Thanks for asking back. Note: JacksEventQueue_put() uses malloc() and also a blocking mutex. This has to be modified to be lock-free (non-blocking). But rather use a different, existing, verified data-structure. jack_ringbuffer is a possible option, for IO to/from the callback. more here: [[ http://wiki.linuxaudio.org/wiki/programming_libraries#lockfree_non-blocking_data_structures_-_libraries }} But don't get lost. The topic is large... ;) Your code looks very clean. I like that you are using C. Emanuel -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Wed, 2012-03-28 at 20:00 +0200, Emanuel Rumpf wrote: Am 28. März 2012 19:33 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 18:31 +0200, Renato wrote: On Wed, 28 Mar 2012 15:35:26 +0200 The mentioned functionality does not depend on a centralized file store. That's right, but that was just _one_ of my possible scenarios. That's the point I'm trying to make, it's not complexity that wins us a bunch of nice features, it's just complexity. It might sound complicated, but your scenario has its difficulties too. Actually I've been talking about a list of filenames, with 3 state flags. How is that sooo complicated ? It's sooo complicated because it forces everything involved to use a special file finding and/or loading interface. It also requires that central store to remain consistent, which is roughly infinity times harder than... well, not. Any program that deletes files based on some fantasy of omniscience isn't one I'm trusting with my data. Actually I think I'd take that a bit farther and say I don't want a session manager deleting files at all. Ever. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 10:47 PM, rosea.grammostola wrote: On 03/26/2012 10:32 PM, Emanuel Rumpf wrote: I've been able now to launch the NON session-manager. - by writing an own simple build-script. ( is my system borked ? or just cmake ?) cmake, iirc it's just ./configure, make, make install I have to say, I'm counting me as a fan of J. Liles Software. Somehow I agree with his style, I would described as unbloated, but still pragmatic and effective. - - - In my opinion NSM is the best approach to session management so far and I'm encouraging every audio-app dev. to jump on this train ! It is non-intrusive, has the required functionality. All though I think I share your opinion here, I do realize that developers jumped on trains before... I can also imagine some frustration if you just added JS to your app and now this new train is coming by. That's why a close research on the characteristics, advantages and disadvantages is important imo. If at the end NSM it as good as it looks, we can jump on that train together without hesitation. We have to be sure somehow that this is a train which takes us where we want to be (blue water with a yellow beach), in such a way that we don't need another train afterwards to be able to reach our destination. - - - There some minor things, I'd like to see: - sessions should have an option to optionally restore window-position and -size of client apps too (would this work for workspaces as well, possibly xinerama ?) I use fluxbox for this. - tools as nsmd, jackpatch, osc_send should show a help message, when started from command line. - the session-manager should have an additional help button, showing a window describing the possible actions (how to duplicate a session, work with templates) - just like non-seq has a window for key-strokes. - in the session-man. there should be a hint where the data is stored. I'd like to always know where it is. Questions remaining: - where would audio apps store large (audio) files ? a custom path ? - appart from large files (audio), all configuration should go to the instances session folder - right ? I am able to save Ardour sessions and share it with my friends. They are able to use them (if Ardour and the right plugins are installed). How is this possible with NSM? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Wed, Mar 28, 2012 at 11:26:16AM +0200, Lieven Moors wrote: So the shared data would not be read-only after all... It is read-only to all the sessions in which it is used for mixdown into some format. It is evidently not read-only to the session that created that data. Isn't this a little bit dangerous? Not if you have a well defined workflow and know what you are doing, and I generally do. I can see this could work with certain kinds of apps that are non-destructive. But how do you know that doing edits to the data in one session doesn't make the other invalid. Because I know what I'm doing. If I edit the original recording for some reason (e.g. replacing a few measures by another take), then I expect the mixdown sessions to pick up the change if they are re-run. If I wouldn't want that I'd duplicate the data into each mixdown session instead. The 'dangerous' thing happens only because I want it. Having the option to do this doesn't affect any other user who doesn't want to do the same. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Wed, Mar 28, 2012 at 11:25 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: I am able to save Ardour sessions and share it with my friends. They are able to use them (if Ardour and the right plugins are installed). How is this possible with NSM? Pretty much the same way you do it with Ardour. Just make a tar.bz2 of the session directory (e.g. ~/NSM Sessions/Songs/The Song I Want To Share) and send it to your friend, they untar it in their session root, and NSM will find it. In the general case, this will work fine. Of course, just like with Ardour, whether the session actually loads and works properly depends on whether or not your friend as the same programs and plugins (or compatible versions of them) installed. Now if you later want to merge the two sessions, you're really on your own. In that case, making your session folder into a git repository would probably work better than just using tar. Non-DAW and Non-Mixer project data is textual and can be meaninfully managed by a line-based diff algorithm like GITs, but MIDI data (Non-Sequencer)--not so much. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] HDSP 9652 and Behringer ADA8000
On Wed, Mar 28, 2012 at 08:44:28AM +0900, Phil T wrote: Im would like to experiment using microphone arrays ( 24 channels ) and I am just wondering if it is possible for me to use 3 units of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools run only with ALSA supported devices and I checked through ALSA website, the HDSP 9652 seemed to be OK. Im just wondering if the set-up I mentioned is possible ? Will there be any issue at all if i use the ADA8000 as far as ALSA is concerned ? Thank you very much, I really would appreciate any suggestions or comments. Thank you Microphone arrays usually mean you need well-defined or at least repeatable and stable gain settings. This is quite problematic with the ADA8000. Also if you build them into a portable rack case make sure you leave plently of open space between them. Some of my collegues here put four ADA8000 on top of each other in 6U rack - just 1U space at the top and bottom. Three of them were fried. You only know when the damage is done. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/28/2012 10:43 PM, J. Liles wrote: On Wed, Mar 28, 2012 at 11:25 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: I am able to save Ardour sessions and share it with my friends. They are able to use them (if Ardour and the right plugins are installed). How is this possible with NSM? Pretty much the same way you do it with Ardour. Just make a tar.bz2 of the session directory (e.g. ~/NSM Sessions/Songs/The Song I Want To Share) and send it to your friend, they untar it in their session root, and NSM will find it. In the general case, this will work fine. Of course, just like with Ardour, whether the session actually loads and works properly depends on whether or not your friend as the same programs and plugins (or compatible versions of them) installed. Now if you later want to merge the two sessions, you're really on your own. In that case, making your session folder into a git repository would probably work better than just using tar. Non-DAW and Non-Mixer project data is textual and can be meaninfully managed by a line-based diff algorithm like GITs, but MIDI data (Non-Sequencer)--not so much. Nice. I've to find another question or user scenario then, which will proof that NSM sucks anyway. People who can help me with this, don't hesitate to drop it on the list! Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] HDSP 9652 and Behringer ADA8000
On Wed, Mar 28, 2012 at 09:03:24PM +, Fons Adriaensen wrote: [ADA-8000] other in 6U rack - just 1U space at the top and bottom. Three of them were fried. You only know when the damage is done. I've just replaced a broken capacitor in an ADA-8000's power supply yesterday. No idea if there's more to break, though. ;) Do you happen to know the symptoms in your case? Anyway, channel 5 here always had some serious hum at -60dBFS, so I guess I have to open it again. Yet another story why the ADA-8000 gained a reputation for poor reliability. Cheers -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/28/2012 10:20 PM, rosea.grammostola wrote: On 03/28/2012 10:43 PM, J. Liles wrote: On Wed, Mar 28, 2012 at 11:25 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: I am able to save Ardour sessions and share it with my friends. They are able to use them (if Ardour and the right plugins are installed). How is this possible with NSM? Pretty much the same way you do it with Ardour. Just make a tar.bz2 of the session directory (e.g. ~/NSM Sessions/Songs/The Song I Want To Share) and send it to your friend, they untar it in their session root, and NSM will find it. In the general case, this will work fine. Of course, just like with Ardour, whether the session actually loads and works properly depends on whether or not your friend as the same programs and plugins (or compatible versions of them) installed. Now if you later want to merge the two sessions, you're really on your own. In that case, making your session folder into a git repository would probably work better than just using tar. Non-DAW and Non-Mixer project data is textual and can be meaninfully managed by a line-based diff algorithm like GITs, but MIDI data (Non-Sequencer)--not so much. Nice. I've to find another question or user scenario then, And/ or developer scenario's of course. E.g. examples how hard and cumbersome it is to add NSM support to an application, especially with certain applications. The disadvantages of the API, the problems you get when you want to use it crossplatform, or without a graphical interface, etc. etc. which will proof that NSM sucks anyway. People who can help me with this, don't hesitate to drop it on the list! Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] HDSP 9652 and Behringer ADA8000
On 03/28/2012 11:25 PM, Adrian Knoth wrote: On Wed, Mar 28, 2012 at 09:03:24PM +, Fons Adriaensen wrote: [ADA-8000] other in 6U rack - just 1U space at the top and bottom. Three of them were fried. You only know when the damage is done. I've just replaced a broken capacitor in an ADA-8000's power supply yesterday. the same happend here once. another one has problems with the phantom power, it is sometimes (unpredictably) disappearing on some channels, making it unusable for recording. Gains tend to drift and are hard to adjust. A third one has a low frequency noise on one channel. The fourth one is fine right now, although the delay is slightly different to the other three ones (about 0.5ms difference)... Until now I had no problems with the outputs of the ADA8000. Recently I made a recording (lute singing), partly with ADA8000, partly with RME Micstasy, both with the same Neumann mics, and I could barely hear the difference... Giso No idea if there's more to break, though. ;) Do you happen to know the symptoms in your case? Anyway, channel 5 here always had some serious hum at -60dBFS, so I guess I have to open it again. Yet another story why the ADA-8000 gained a reputation for poor reliability. Cheers ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
