[14:04] <scott-work> ailo: astraljava: len-dt: and anyone else interested:
[14:05] <scott-work> talk has started again with UKT perons about -lowlatency kernel maintenance 
[14:05] <scott-work> the thrust of it appears to be as follows:
[14:05] <scott-work>  * UKT will create the -lowlatency kernel and attend to it during development of any particular release (e.g. during Q)
[14:06] <len-dt> scott-work, what about precise?
[14:06] <scott-work> * a UKT designate (probably andy whitcroft, who is knows as apw) will document the rebasing procedure for our benefit
[14:07] <scott-work> * a similar UKT designate will set up an automated bug report that will notify us when a we need to rebase (which i believe will be most times for security updates)
[14:08] <scott-work>  * we need to identify people interested in shouldering this responsibility
[14:08] <scott-work> * we already have created a ubuntu studio kernel team
[14:08] <len-dt> scott-work, do we still have someone in our team who is doing anything with kernels?
[14:08] <scott-work> * UKT will mentor us on the process
[14:08] <scott-work> * we will rebase as needed and propose for sponsorship
[14:09] <scott-work>  * i believe UKT will then upload after checking
[14:09] <scott-work> len-dt: wrt precise, i'm less "precise" about what is happening there
[14:09] <scott-work> (hahahaha, i keeeel myself)
[14:10] <scott-work> UKT may be handling that for the time being since it appears to be needing updates, but i may be wrong
[14:11] <scott-work> i would expect that they will help us (i.e. do it) this transgression and when we are educated and mentored, then we will be responsibile
[14:11] <len-dt> ok.
[14:11] <scott-work> len-dt: wrt "doing anythign with kernels" - i believe ailo, astraljava , and i have expressed interest in doing this
[14:12] <scott-work> however, anyone interested can be involved most likely (unless 500 people volunteer)
[14:16] <len-dt> I've/am pretty much used up my time right now. I need to get involved with pulse a bit it seems... I have some ideas for it that will make it more usable in a pro audio environment.
[14:17] <len-dt> There is a configuration change that would affect pulse even when jackd is not running.
[14:18] <len-dt> I don't know if it is available now, but it should be accessible from a gui, preferably theirs but ours if need be.
[14:27] <ailo> scott-work: I've already spent quite some time studying kernel maintenance, and would gladly take the responsibility
[14:28] <ailo> It's not a huge job to do the work though. It's just a few commands
[14:36] <scott-work> ailo: i expect it will be easier than you might think because i believe UKT might create scripts to assist us
[14:36] <scott-work> ailo: len-dt astraljava : oooh, one big thing i forgot....we will need to provide testing of the kernel
[14:36] <scott-work> i.e. before proposing a rebased kernel for upload, we will need to test the kernel
[14:37] <scott-work> UKT really isn't set up to validate a lowlatency kernel, as you might expect
[14:37] <scott-work> and since we are the experts on lowlatency kernels, we should do the testing
[14:37] <len-dt> I don't mind testing if it comes as a deb
[14:37] <scott-work> len-dt: that is understandable, wrt your time
[14:38] <scott-work> len-dt: we might be able to set up a kernel testing ppa that would make it more accessible
[14:39] <len-dt> That would be fine. The last time a packaged our default-settings package (for sru to precise) it took forever...
[14:39] <len-dt> and there was not compiling involved.
[14:49] <scott-work> my work flow for testing is probably not as cool as others (like micah) but...
[14:50] <scott-work> i like a dedicated physical machine upon which to test
[14:50] <scott-work> and i install the dev OS on it
[14:50] <scott-work> i tend to use another, stable machine to handle all the code and push to ppa
[14:50] <scott-work> and i add the ppa to the dev machine and update it to test
[14:50] <scott-work> i feel like that is more accessible, tangible, and understandable
[14:51] <scott-work> i've done some stuff in a chroot (like prevu) but i'm still not completely comfortable with it yet as i don't understand enough of the aspects
[15:08] <len-dt> ailo, scott-work http://www.ovenwerks.net/UStudiodocs/workflow-menu.html
[15:09] <len-dt> ailo, that is based on the flow you gave me yesterday.
[15:10] <len-dt> probably the help item should be at the top on all of them. Something better than the transmission icon would be nice for the menu too :-)
[15:15] <len-dt> The help icons would all have to have their own desktop file anyway and so could also have text that said "understanding workflows" for the main workflow menu. "Which workflow should I use" for the four types of projects (like audio production in this case). The workflow itself wold have "Using the Audio Editing Workflow"
[15:17] <len-dt> ailo, scott-work, there has been talk about a workflow only menu and a utilities menu. I am not sure where to go with that.
[15:18] <len-dt> Would the utilities menu also be broken down into submenus and sub-subs?
[15:18] <len-dt> Is the idea to be able to do all studio work without ever having to use the main menu?
[15:20]  * len-dt doesn't ask enough questions...
[15:24] <len-dt> ailo, there are after adding the apps as you suggest rather a lot of apps left over in the menu spec that have not been placed. These would be used from the main menu.
[15:36] <ailo> scott-work: It is quite easy following scripts, until you get problems, like you would with the -lowlatency that is uploaded to precise right now. In which case, the scripts are useless
[15:36] <ailo> But, as long as things work smoothly, yes, it is quite easy
[15:39] <ailo> scott-work: I'm currently working on testing scripts for US.
[15:39] <ailo> scott-work: And I have multiple machines set up to do testing myself
[15:40] <ailo> len-dt: What you have done is how I designed the structure for the main menu
[15:41] <len-dt> What I have done can be put any place, I don't want to mess up my main menu...
[15:41] <ailo> len-dt: Later, since you preferred a workflow menu outside of the main menu, I made a new structure, but both are just sketches
[15:43] <len-dt> What I have done has two purposes, it shows how a menu would look in a different location and it shows us the work involved
[15:43] <ailo> scott-work: I expect the people who will be doing most of the testing will be len and me
[15:43] <ailo> scott-work: And since I'm the one into kernels, would make most sense if I maintained it
[15:45] <len-dt> ailo, Changing topics once again... I have been looking at pulse configuration.
[15:46] <len-dt> It appears we can set pulse not to play with alsa device controls, but not on a per-device basis
[15:48] <ailo> len-dt: You mean you can set PA to not control any of the levels of the card?
[15:55] <len-dt> I have to test it, but it looks like there are two or three modules that deal with alsa device setting.
[15:55] <len-dt> They can be not loaded.
[15:56] <len-dt> I am tired of setting my levels to use with jack and having pulse reset them as soon as jack is notrunning
[15:57] <len-dt> I find the monitor mixer on the d66 quite useful but pulse keeps turning it off.
[16:03] <len-dt> ailo, I set up my mic/instrument pre so I am under clipping, then set my alsa controls (mudita24) so my digital levels are not clipping. Now I start audacity which grabs pulse... pulse sets my input levels to whatever it last remembers they should be... if I  change levels inside pulse it changes them too.
[16:03] <len-dt> I would like pulse to deal with the device the same as it deals with jacksink/source.
[16:08] <ailo> len-dt: Are you saying pulse controls your d66 internal hw levels? Cause it doesn't for me
[16:12] <ailo> oops. need to get going. Participating in an event. 2km uphill
[16:13] <len-dt> bye
[16:27] <len-dt> ailo, when you get back... it appears it has been jackd all along. I like to set my routing up so that H/W out 1&2 are connected to the digital mixer.
[16:29] <len-dt> In qjackctl I have set up H/W meter and figured H/W monitor too.
[16:31] <len-dt> Well, setting H/W monitor lets jack set my H/W Out 1& 2 to PCM out.... bypassing the monitor mixer.
[16:37] <len-dt> ailo, to my mind qjackdctl has things backwards. H/W monitor is on when unchecked and off when checked.
[16:38] <len-dt> Or perhaps jackd moves the connections the wrong way.
[16:39] <len-dt> Or the ALSA switches in the ice1712 driver are backwards to everything else.
[16:48] <len-dt> I guess the reason I figured pulse played with my d66 settings is because it does play with my HDA settings. (netbook)
[17:54] <ailo> len-dt: The "Monitor" button creates a double set of HW inputs. It's not related to the internal monitoring of cards
[17:55] <ailo> len-dt: If you want to enable HW monitoring for your d66, route your output 1 and 2 to digital mixer in mudita24
[17:55] <ailo> Under "Patchbay/ Router"
[17:55] <ailo> That will enable the Levels in "Monitor Inputs" and "Monitor Outputs"
[17:56] <ailo> The Monitor input and output levels become in effect a HW monitor mixer, which does not affect recording levels
[17:56] <ailo> So, no need to use "monitor" in qjackctl.
[17:59] <ailo> len-dt: Just remember to unmute the "Monitor" levels to get sound
[18:09] <len-dt> ailo, I was not talking about the monitor button but the H/W Monitor button just above H/W meters.
[18:10] <len-dt> man jackd says it will:
[18:11] <len-dt> Enable hardware monitoring of capture ports.
[18:11] <len-dt> "When  enabled,  requests to monitor capture ports will be satis‐
[18:11] <len-dt>               fied by creating a direct signal path  between  audio  interface
[18:11] <len-dt>               input and output connectors, with no processing by the host com‐
[18:11] <len-dt>               puter at all.  This offers the lowest possible latency  for  the
[18:11] <len-dt>               monitored signal."
[18:13] <len-dt> I'm not sure what this means, but I have decided that it is much easier to set this up with mudita24 than with jack and whatever.
[18:13] <len-dt> (using the method you describe, which is how I expected to BTW)
[18:16] <len-dt> I am guessing, that jack can request an internal connection from a capture port to a playback port that mudita doesn't see.
[18:17] <len-dt> But the jack list of connections does see.
[18:19] <len-dt> I would rather use the digital mixer/mixbus
[18:22] <scott-work> the word appears that andy from UKT will update the lowlatency kernel in precise
[18:23] <scott-work> len-dt: that image is pretty awesome!
[18:24] <scott-work> (i ignored the transmission icon, too ;) )
[18:24] <scott-work> are we leaning to using a "dock" versus the top panel (where the main menu is)?
[18:25] <len-dt> scott-work, that points out the major outlay in time would be... icons.
[18:25] <scott-work> i realize that it really isn't a "dock" but just another panel, but it is modified to look like a dock
[18:25] <scott-work> len-dt: understood, i like it
[18:25] <len-dt> The top bar is a panel the bottom one is a panel.
[18:25] <len-dt> I just like my panel to the side.
[18:26] <scott-work> i realize that about the panels, just visually the bottom (and your side) panel is designed to look like a "dock"
[18:26] <scott-work> len-dt: i do the same actually
[18:26] <len-dt> You may also notice I have fewer icons than stock.
[18:26] <scott-work> i think we should also probably change the language of the menus to reflect work flows as the intent of the menu
[18:27] <scott-work> aye
[18:27] <scott-work> ^^ fewer icons
[18:27] <scott-work> i'm really liking the accessibility of this, but the separation from the main menu
[18:29] <len-dt> scott-work, it could be just as easily a part of the top panel just like the old gnome bar has main menu, places, system.
[18:30] <len-dt> If so I would recommend enabling text next to the icon.
[18:40] <scott-work> len-dt: agreed on the text next to the icon!  most defintely
[18:40] <scott-work> len-dt: do you think it should be on the top panel?
[18:40] <len-dt> scott-work, I have no preference.
[18:41] <scott-work> i'm not sure that is the best place as i really like the separation, the physical separation is kinda representative of the separation of intent
[18:41] <len-dt> my feeling is that I would use the main menu.
[18:41] <scott-work> len-dt: i think if it is uncluttered (i.e. no system, office, interent) then it would be preferable to me
[18:41] <scott-work> and maybe others as well
[18:42] <len-dt> To be more plain, I think the idea has merit, but it has more use for someone who doesn't know the applications than someone who does.
[18:42] <scott-work> just like how we separate audio apps from video apps, having content production apps away from non-content production apps
[18:42] <len-dt> It is a personal thing though. I don't have anything against it.
[18:42] <scott-work> yeah, agreed, neither is right or wrong ;)
[18:43] <scott-work> but this would replace some of the things i had set up on my old rig (that i haven't set up again on my 12.04 machine)
[18:43] <scott-work> i just like having a simple and very immediate place for clicking on the items i use the most (like jack, ardour, hydrogen for audio)
[18:44] <len-dt> I also don't mind it taking up space on one panel or another and would not remove it.
[18:46] <scott-work> len-dt: speaking of "one" space...what if a dock had a single "space" for each discipline?
[18:46] <scott-work> or would that be silly for the video or graphical ones currently where there isn't much under the work flow at this point?
[18:46] <len-dt> That could be better.
[18:47] <scott-work> it could be a "work flow" dock (yeah, it's a panel disguised as a dock)
[18:47] <len-dt> Ubuntustudio needs to place the same emphasis on video,graphics,photography and publishing as on audio.
[18:48] <scott-work> i agree with that!!!!!
[18:48] <len-dt> So menuing and workflows should be just as elborate for them too.
[18:48] <scott-work> i really believe the potential is there with the other apps becoming more robust and mature, we just need to develop the knowledge and experience
[18:50] <len-dt> even if there are only two workflows for the other sections, they will still be three deep.
[18:51] <len-dt> So having a menu for each (5 in all) would make that only 2 deep.
[18:52] <len-dt> ailo suggested to have one utils directory (or controls or whatever), but I would do one for each of the core products in its own menu
[18:54] <len-dt> scott-work, the only thing is that I don't know how to make it so only the workflows installed are shown.
[18:55] <len-dt> There is some work going on to make the life install more like the alt... sort of combined without doubling the size of the ISO
[18:55] <len-dt> s/life/live
[18:56] <len-dt> So if someone doesn't install graphics then the graphics menu shouldn't show up either.
[18:58] <scott-work> len-dt: hmmmm, good question
[18:59] <len-dt> Also, once the user's directory has been created and logged into. The panel can no longer be modified. xfce uses a copy in the user's home. The workflow menu can be changed though.
[18:59] <scott-work> which reminds me, we need to sort out that ubiquity plugin pretty soon or else it will delayed again antoher cycle
[18:59] <scott-work> i was hoping astraljava would be available to complete this task
[19:06] <len-dt> In an email from Emmet HIKORY, Where we talked about selecting metas at install time, he suggested there was change in the air and to find out what. His words "as it would be exceedingly frustrating to
[19:06] <len-dt> generate a solution that needed significant rework prior to release"
[19:06] <len-dt> scott-work, ^^
[19:07] <scott-work> mmmm, sounds slightly ominous
[19:07] <len-dt> The whole text is on the list july 28
[19:08] <len-dt> topic is: Re: Another idea for comments
[19:08] <len-dt> It is the last paragraph.
[19:09] <len-dt> There has already been changes, in 12.04 everything is copied to disk and then stuff not needed is removed. in 12.10 this has changed and ubiquity tries to detect what files not to copy in the first place.