Re: [LAD] LADI
On 12/21/2009 10:18 AM, torbenh wrote: On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea grammostola wrote: torbenh wrote: On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote: What can we expect from group 2? Maybe some of the lash developers belongs in this group? Dave, Juuso, Bob Ham, ... ? What are your plans now? dunno... jack session is frozen now. Torben, thanks for your reply. Can you, for the people who didn't follow the development of jack session, shortly point out what jack session does. 1) What do you want to achieve with jack session. session management ? load/save of whole jack graph . 2) How do you think you are able to achieve it? with very few exceptions every app thats a target for session management, is a jack client. so why not add some callbacks, and let the sessionmanager communicate with apps via jack ? this basically reduces the size of the app patches. allowing me to patch at least one app per hour. 3) Why do you think this is the best way to do it? every app is already using jack IPC to communicate with jackd. - minimally invasive on the app. no reinvention of the wheel or yet another IPC mechanism to add. anyways... effort is frozen. we are dumping a working implementation. I don't understand why you have made this decision. The basic framework that you have implemented will be very useful for a large subset of the requirements of a session management system. In may be more than enough for 95% of normal users to get things done. If people need to take things further they have the option of using LADI or waiting for Fon's to release his work. There was only one person who categorically said they wouldn't be able to work with your additions and he is already making his own system anyway. I would like to see your work included as an option as that would also give Nedko (and maybe even Fons) an opportunity to extend and integrate their efforts to work with yours. Wholesale writing off your efforts simple because the debate got heated seems unnecessary to me. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
This is probably because the Jacksession version would need to maintained in a seperate branch, and so we'd have 3 versions of jack to deal with. I tested jacksession, and it works well. (Using the experimental branch) As Torben says, there's minimal intrusion in apps, and importantly minimal change to the jack API. I'm sorry to see it stop, but Torben's been driving this forward, as a practical opportunity for users, and not just a lot of discussion, and if he feels the politics (and i think that is what's at the heart of this) of doing this outweighs the positive benefits, then i can hardly blame him for freezing it indefinitely or otherwise. Why keep bashing your head against the wall? If he decides to pick this up again, and take it further, then i'm willing to continue testing, as i see jacksession as the simplest, most elegant, and least intrusive session management system i've seen to date. That's i guess, the best we can do for now. The users will have to wait, find another way, or just accept it's not going to happen. Alex. On Mon, Dec 21, 2009 at 8:54 AM, Patrick Shirkey pshir...@boosthardware.com wrote: On 12/21/2009 10:18 AM, torbenh wrote: On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea grammostola wrote: torbenh wrote: On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote: What can we expect from group 2? Maybe some of the lash developers belongs in this group? Dave, Juuso, Bob Ham, ... ? What are your plans now? dunno... jack session is frozen now. Torben, thanks for your reply. Can you, for the people who didn't follow the development of jack session, shortly point out what jack session does. 1) What do you want to achieve with jack session. session management ? load/save of whole jack graph . 2) How do you think you are able to achieve it? with very few exceptions every app thats a target for session management, is a jack client. so why not add some callbacks, and let the sessionmanager communicate with apps via jack ? this basically reduces the size of the app patches. allowing me to patch at least one app per hour. 3) Why do you think this is the best way to do it? every app is already using jack IPC to communicate with jackd. - minimally invasive on the app. no reinvention of the wheel or yet another IPC mechanism to add. anyways... effort is frozen. we are dumping a working implementation. I don't understand why you have made this decision. The basic framework that you have implemented will be very useful for a large subset of the requirements of a session management system. In may be more than enough for 95% of normal users to get things done. If people need to take things further they have the option of using LADI or waiting for Fon's to release his work. There was only one person who categorically said they wouldn't be able to work with your additions and he is already making his own system anyway. I would like to see your work included as an option as that would also give Nedko (and maybe even Fons) an opportunity to extend and integrate their efforts to work with yours. Wholesale writing off your efforts simple because the debate got heated seems unnecessary to me. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Sun, Dec 20, 2009 at 11:18 PM, torbenh torb...@gmx.de wrote: anyways... effort is frozen. we are dumping a working implementation. Can you summarise why, for people like me who haven't read any of the interim discussion? Thanks... Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
You have no disagreement from me in any of the points you've made. Alex. On Mon, Dec 21, 2009 at 9:34 AM, Patrick Shirkey pshir...@boosthardware.com wrote: On 12/21/2009 08:22 PM, alex stone wrote: This is probably because the Jacksession version would need to maintained in a seperate branch, and so we'd have 3 versions of jack to deal with. I tested jacksession, and it works well. (Using the experimental branch) As Torben says, there's minimal intrusion in apps, and importantly minimal change to the jack API. I'm sorry to see it stop, but Torben's been driving this forward, as a practical opportunity for users, and not just a lot of discussion, and if he feels the politics (and i think that is what's at the heart of this) of doing this outweighs the positive benefits, then i can hardly blame him for freezing it indefinitely or otherwise. Why keep bashing your head against the wall? If he decides to pick this up again, and take it further, then i'm willing to continue testing, as i see jacksession as the simplest, most elegant, and least intrusive session management system i've seen to date. That's i guess, the best we can do for now. The users will have to wait, find another way, or just accept it's not going to happen. I haven't seen anything on the lists that implied or suggested that jack_session would not be applied to Trunk once it was decided it was ready for wider testing. I have been expecting that to happen and am quite surprised that Torben has decided to freeze development. Is there some debate on irc that I have missed in the past two weeks? Just cos one person has strongly objected to it doesn't mean it shouldn't be made an optional feature for the rest of us to have access to. It can always be disabled at compile time. It doesn't add bloat, it can be integrated with LADI, it is just a few additional callbacks, it's simple to integrate and it enables at least 80% of functionality for a normal users session management requirements. I would like to find out if it the remaining 20% is even needed by the majority of users. IIUC the current implementation is only missing support for undo. There are a couple of proposed options for the other issue of handling application naming conflicts. Any one of those options if implmented will be better than we have now. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] High-res PPQn
Hello list, I recently wrote a sequencer for multi-touch/collaborative music composition as part of my thesis. I currently set the PPQ to 128 which ought be enough for demonstration purposes and early testing. Now, I am wondering how to support higher PPQN efficiently. Some of you guys might have an experience in doing that; I've seen that renoise supports up to 4096 PPQN and DigitalPerformer uses some kind of variable clocking. Have you heard or implemented of techniques that are smarter than just cranking up the _fixed_ clock resolution? As timestamps I currently use 64bit ints, I guess I could encode the timing as (tick, +subdivisions) and poll the timing for the next event(s) and set the clock accordingly. Would that be worth it? Any general opinions about the max PPQN? thanks, so long... Niklas ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
