[00:02] <ailo> macinnisrr, The way they did it before was let firewire devices be accessed using Video group, which was needed for realtime. Now, they are accessed through audio group. The file is in /lib/udev/rules.d/60-ffado.rules
[00:03] <ScottL> ailo, in a couple of hours i want to do some kernel testing
[00:03] <ailo> In that file, each supported firewire device is added to audio group separately, so not everything "firewire" is getting realtime 
[00:03] <ScottL> will you be available to tell how you want the test done or provide a link to the instructions?
[00:04] <ailo> ScottL, https://wiki.ubuntu.com/generic_vs_lowlatency_testing
[00:04] <ailo> ScottL, I think you get the idea from the "Quick Instructions"
[00:05] <macinnisrr> ailo: yeah. So the ubuntustudio-controls package in main still points to the old files? That should be changed immediately if we can. I'd be happy to pass my files along (I'm currently in the process of properly packaging all my apps for adding to my ppa, and will notify as soon as they're all ready).
[00:05] <ailo> macinnisrr, ubuntustudio-controls is being removed from Natty, I believe
[00:05] <ailo> macinnisrr, It's not really serving any function at the moment
[00:05] <ailo> macinnisrr, But, it would need to be updated for Lucid and Maverick separately
[00:06] <macinnisrr> ailo: really? what about memory lock? I've had my display lock up using "unlimited", and not everyone knows how to edit config files at the command line.
[00:06] <ailo> macinnisrr, You should tell las about that. He seems to think that nothing bad can come from using "unlimited"
[00:07] <ailo> macinnisrr, I have that function on my version of the -controls as well, but sadly it did not make it into this release
[00:08] <macinnisrr> ailo: I know, and I have (I left a post about it on the ardour forum), but I must admit that those issues were on jack1, maybe it doesn't matter with jack2.
[00:08] <ailo> no idea. jackd1 is still being used on occasion, though
[00:09] <macinnisrr> ailo: for sure. My live mixing PC still uses Lucid/jackd1.
[00:10] <macinnisrr> Dream Studio uses a memory lock of 1024MB by default for this reason, but it's easy enough to adjust with -controls
[00:11] <ailo> macinnisrr, The best would be for an application to check the memory size at each login and rewrite the file according to a percentage
[00:11] <ailo> macinnisrr, I should add that to my -controls
[00:12] <ailo> The memory can change between boots
[00:12] <ailo> And it can very well be under 1024, even if that is not so smart with newer releases
[00:13] <macinnisrr> ailo: I agree. I just started writing scripts when I created Dream Studio, but I could probably make something like that now.
[00:32] <ailo> ScottL, I have an additional idea about your dock and profiles. Having those synced with workspaces. When changing profile, all open applications in that profile are restored. So, you don't really change workspace. Bit, it has the same effect. Even better if you can have the same app appear in many workspaces, or profiles
[00:33] <ailo> Well, if you can understand my poor explanation of it..
[00:34] <macinnisrr> ailo: are you suggesting that an application should open on multiple workspaces, or that if you open multiple applications they should be spread out amongst available workspaces?
[00:35] <ailo> Instead of workspaces like now, you would have profiles, and one application could appear in many profiles. Changing a profile would minimize applications fro the previous profile, and restore the ones in the profile you just chose
[00:35] <ailo> Like workspaces, but in the same window. 
[00:36] <ailo> And some applications could appear in two or more
[00:36] <macinnisrr> ailo: sort of like ardour profiles, but for the whole desktop?
[00:37] <ailo> I like Firefox way of using pinned tabs. In Firefox you can group your tabs, and change between groups, but pinned tabs will be visible in all groups
[00:37] <macinnisrr> very interesting.
[00:37] <macinnisrr> I have no idea how to implement such a thing, but I think it's a good idea
[00:37] <ailo> It would need some coding I guess. Something that is added to a panel.
[00:38] <ailo> You should be able to change the set of launchers on it, by choosing between profiles, and also when choosing another profile, it would minimize and restore applications. Gnome panel functionality.
[00:40] <ailo> macinnisrr, It was ScottL's idea to have workflow based set of launchers in a dock. And by changing "profile" you get a different set of launchers.
[00:40] <ailo> My idea was to add a sort of workspace functionality to it as well
[00:40] <macinnisrr> ailo: so it would be like the workflow idea Scott had, but would additionally minimize apps that aren't part of the profile (and show apps that are)?
[00:40] <ailo> macinnisrr, Right
[00:41] <ailo> I suppose not adding an app to a profile would make it unaffected, and some apps could be added to more than one profile
[00:42] <macinnisrr> ailo: neat.
[00:42] <ailo> If Unity's panel was used, I would like to be able to choose profiles with the mouse scroll. And I would like a + button, to open all profiles, next to each other
[00:43] <macinnisrr> once again, I like the idea, but have no clue how it could be done. Can you send a message to certain applications to minimize/unminimize (via Dbus maybe, or similar)?
[00:43] <ailo> macinnisrr, In whatever way the panels do that.
[00:43] <ailo> I haven't found out how that works either
[00:44] <macinnisrr> ailo: I didn't know the panels had anything to do with it. I thought it would be the window manager solely that handled such things.
[00:44] <macinnisrr> and that the panels simply displayed anything fed to them by the window manager.
[00:45] <macinnisrr> ailo: I think basically what you'd need is a sort of "show desktop" function that was selective about which programs it applied to.
[00:45] <ailo> macinnisrr, In panels you usually have those functions. But, I'm sure you can use any application to control other applications behaviout
[00:46] <ailo> Not the panel itself on Gnome2
[00:46] <macinnisrr> behavior
[00:46] <macinnisrr> :-)
[00:47] <macinnisrr> ailo: sorry, I don't mean to correct you. I actually just glanced at the screen and though I had made the error.
[00:47] <macinnisrr> thought
[00:47] <macinnisrr> ha! That time I did.
[00:48] <ailo> I guess the "addition" to whatever dock or panel one would like to use for this, would contain the same sort of functionality on windows as for instance the Windows List applet does in the gnome2 panel
[00:48] <ailo> It would require some coding, anyhow
[00:48] <ailo> macinnisrr, Yeah, I guessed as much :)
[00:49] <ailo> I should work on some things now. Really, I need to get away from US for a while now..
[00:49] <ailo> :P
[00:50] <macinnisrr> hmmm...Well, the Unity dock already handles everything the "windows list" applet does (and lenses too), so maybe it would require hacking unity itself. 
[00:50] <ailo> macinnisrr, Exactly
[00:50] <macinnisrr> ailo: right on.
[00:50] <ailo> macinnisrr, Or adding a plugin, or something
[00:51] <ailo> macinnisrr, If it is Unity's panel that is to be used, that is.
[00:51] <macinnisrr> ailo: I'll bring this up with the unity developers; I'm sure lots of users would like this (not just creative types).
[00:52] <ailo> macinnisrr, It would make a lot of sense, wouldn't it? At least as an expansion tweak.
[00:52] <ailo> Great to have on touchscreens as well
[00:53] <macinnisrr> ailo: even if many would never use it, one would think it would be trivial to code, and yes, as you say, it would be great for touchscreens (which Unity is made for, and the way PCs are going, even if not full time).
[00:55] <ailo> Another thing I've been thinking about for a long time, and I did consider a side panel for that, is that the panel would change according to the program. Now, there's a menu at the top, but on touch screen especially, I think one wants the menu in the form of bigger buttons on the sides.
[00:55] <ailo> And accessing the main menu would simply need a touch in the high corner, to change the panel to a main system menu instead
[00:56] <macinnisrr> personally, for Dream Studio, I'm looking forward to having a tablet with touchscreen that I can do all my mixing/graphics/video editing on. A device like that already exists, and our software (Ubuntu) is working towards it. This would be a killer feature. Even iPad users can't edit video or mix/master their album, and even when they can do limited versions of these things, their software is not the same as the des
[00:56] <macinnisrr> ktop, so compatibility issues arise.
[00:57] <macinnisrr> ailo: As I understand it, Unity's hidden menus are designed to move developers towards menuless interfaces.
[00:57] <ailo> macinnisrr, Seems like the right move
[00:58] <macinnisrr> I can't find the post right now, but there was an article on omgubuntu.co.uk about dock mockups, whereby clicking the BFB would rotate the dock to add extra functionality that isn't just app launchers. I hope they go through with this.
[00:59] <macinnisrr> a changing menu like you mention would be perfect in such an implementation
[00:59] <ailo> macinnisrr, Sounds like they are already doing a lot of that, then
[01:00] <ailo> It's amazing how much you can do with just searching too, now that you are not only searching for the application name. Tags for functions, synonyms and so on
[01:03] <macinnisrr> ailo: absolutely. Zeitgeist is huge too, as it tracks your usage patterns and returns relevant results. Zeitgeist integration, as I understand, was one of the main reasons Ubuntu went with Unity as opposed to Gnome3 (as they didn't want to use Zeitgeist).
[01:03]  * holstein high-fives ailo & macinnisrr 
[01:04]  * holstein is busy and cant stay
[01:04]  * macinnisrr enjoys the high-five
[01:04] <ailo> Hi holstein
[01:04] <holstein> i like seeing activity though :)
[01:04] <macinnisrr> bitchin
[01:04] <holstein> hehe
[01:06] <ailo> macinnisrr, It's not a bad thing really that Unity and Gnome3 are so alike. They can compete, and not feel bad about using each others code (I'm assuming Unity is open source).
[01:09] <macinnisrr> ailo: it is. Over the last six months, I've read lots of posts about unity. At first, the consensus was "why ditch gnome", then it turned into "unity doesn't work, use gnome2 instead", then "unity is better than gnome3, but still needs work". Give it till October, and I'm sure most people will be back to "Ubuntu rocks".
[01:09] <macinnisrr> ailo: it is open source, that is.
[01:12] <macinnisrr> BTW, I totally agree with the philosophy behind Unity (use the best UI ideas from ALL OSes, and lose the cruft), and am also looking forward to wayland as the default display server. Tradition is nice, but when it hinders innovation, it's useless. Not to mention the fact that anyone who prefers Gnome2 and X.org probably knows how to install them.
[01:52] <ailo> ScottL, I added a couple of ideas at the bottom https://wiki.ubuntu.com/UbuntuStudio/Workflows
[02:01] <ScottL> i'll be starting the test in about 30 mins and i'll check out the workflows too
[02:07] <ailo> ScottL, Just by opening GIMP and compressing or uncompressing a file at the same time takes up the whole CPU with non realtime activity. I have had a feeling that graphics have sometimes interfered with audio processes, but in this case, at least for me, it seems the only thing slightly affecting jackd was using the CPU to maximum with non realtime activity. And, it needs to hit maximum for me, for there to be a disruption
[02:08] <ailo> For realtime activity it is the same thing, except it will most certainly disrupt audio and cause xruns at maximum CPU usage.
[02:09] <ailo> generic was only ever so slightly worse off when I compared my onboard cards, but enough for the results to be different
[04:21] <ScottL> ailo, i did some tests
[04:22] <ailo> ScottL, Were you using the command line to start jackd?
[04:22] <ScottL> although i admit that i wasn't really using ardour while testing, it was on and running but i wasn't recording
[04:22] <ScottL> no, i was using qjackctl
[04:22] <ailo> Those are some pretty low ms values
[04:23] <ScottL> the funny thing is that i wasn't in the audio group for the first pass through both
[04:23] <ScottL> i was getting horribly high values and they were apparently the same
[04:23] <ScottL> ailo, i've alway, i mean _always_, gotten good latency performance with dell p4 machines, even with onboard sound
[04:24] <ailo> Those values are pretty spectacular
[04:25] <ailo> When I added 11.6ms for one of the generic tests, I only got one xrun
[04:25] <ailo> It was that close to the -lowlatency value, but not when using ice1712
[04:25] <ScottL> i thought they were amazing as well, i was quite surprised as well
[04:25] <ScottL> i had expected pretty good, but not that good
[04:26] <ailo> Wait, I meant, when I added 11.6ms for generic in one of my tests, I only got one xrun at 5.8ms,
[04:26] <ScottL> right, i was doing the same, one xrun meant i used the previous settings as good
[04:27] <ScottL> i was archiving files and opening gimp at the same time
[04:27] <ScottL> i even moved the window for file manager while i was doing it
[04:27] <ScottL> sometimes
[04:27] <ScottL> and others i was switching desktops by rolling the roll wheel
[04:27] <ScottL> one thing i should mention...i was on xubuntu as well
[04:28] <ScottL> but comparing actual numbers between users is a little silly
[04:28] <ScottL> we aren't using the same hardware, etc
[04:28] <ScottL> BUT, i think we can see a trend through between -generic and -lowlatency
[04:28] <ScottL> -lowlatency seems to provide a better performance 
[04:28] <ailo> The numbers probably lie somewhat, but still, your results are pretty good, especially for generic
[04:30] <ailo> ScottL, Are you going to repeat the test with your ice1712 card?
[04:32] <ScottL> ailo, probably not
[04:32] <ScottL> i either have to install natty on my main rig or
[04:32] <ScottL> pull the delta card out of my main rig and put it in this test machine
[04:33] <ailo> Even though some would like to say that onboard devices are crap and not usable for pro audio, I think that if you can use them at least for playback, it's a great thing.
[04:34] <ailo> And, with -lowlatency, so far, three machines tested, it works pretty well. Hard to say from the numbers what is a good latency. I'm just guessing anything under 10ms
[04:34] <ailo> The ear can clearly hear 20ms
[04:35] <ailo> The fingers can probably feel less than that
[04:36] <ScottL> i've heard 10ms repeated a lot for human hearing
[04:36] <ailo> At least on my older machine, 10ms was just at the limit of acceptable, but not quite right
[04:36] <ScottL> and it seems that 5-10ms is said quite a bit too...which is probably more true because different people hear different latencies
[04:37] <ailo> ScottL, You can test your ears by using a delay and set it (if you can rely on it)
[04:38] <ScottL> i might upgrade my main rig to natty though, i would be able to test the ice card on a dual core then
[04:38] <ailo> But, playing an instrument, you might not "hear" it. You just feel it's a little odd
[04:38] <ailo> Around 10ms. That's my experience
[04:39] <ailo> So, 5ms I con't think anyone can hear
[04:39] <ailo> And it's not really that personal
[04:39] <ailo> It's more about limitations of human hearing
[04:39] <ScottL> i'm not so sure, eric johnson can hear if a battery is not fresh from a distortion pedal :P
[04:39] <ScottL> s/from/in
[04:40] <ScottL> i think some people are psyiological better
[04:40] <ScottL> at hearing latencies
[04:40] <ailo> In some areas, I expect the differences will be bigger, and of course, if someone is not a musician, they don't have enough experience
[04:41] <ailo> But, in the area of time, don't thing the difference is very big
[04:41] <ailo> It's also closely related to what we can achieve with our hands
[04:42] <ailo> You hear separate hits from a drum until the point where a trained drummer can't hit much faster. Not counting drum rolls, where you do double hits or triple hits per hand
[04:43] <ailo> When you go beyond that speed, it starts to sound like a tone
[04:44] <ailo> Don't remember what the time in between those strokes would be, but I think it's somewhere around 20ms or so
[04:44] <ScottL> going to reboot
[04:48] <ailo> ScottL, http://kb2.adobe.com/cps/331/331631.html
[04:48] <ailo> Check the part "General guidelines that apply to latency times"
[04:51] <ScottL> i believe that most humans can hear up to 10ms, but i've read about some mixer/master professionals who claim to hear less than that
[04:51] <ScottL> that's also why i've tended to accept when people say 5-10ms
[04:51] <ailo> ScottL, You can hear it in a mix, like a phase
[04:52] <ScottL> but i really don't notice it when i'm recording even when it's around 20ms
[04:52] <ailo> ScottL, But, you don't really hear two separate sounds
[04:52] <ScottL> so i guess i'm not super mixer/master material :P
[04:52] <ailo> ScottL, About the battery and distortion, and tonality, the difference is huge
[04:53] <ScottL> well, i also think eric johnson is a freak of nature anyways ;)
[04:53] <ailo> Some people can hardly learn to sing a simple tune, while others hear even the slightest variations in pitch. 
[04:54] <ailo> ScottL, I'm sure that if you spent some more time with it, you'll start to notice 20ms quite easily. 
[04:55] <ailo> To get the actual latency, we would need to use a latency testing program, like the one that I think comes with jackd. You need to plug the output to the input
[04:55] <ScottL> ah, my son finally fell asleep, time for bed for me as well
[04:55] <ScottL> goodnight ailo
[04:55] <ailo> ScottL, GN
[06:48] <Kokito> howdy
[19:04] <scott-work> ailo: when you were doing your kernel testing, what exactly were you doing with ardour?
[19:04] <scott-work> ailo: just running ardour? playing something back? recording audio?
[19:04] <ailo> scott-work, Only recording and playback
[19:04] <scott-work>  
[19:05] <scott-work> ailo: tonight i will redo the test to record and playback then
[19:05] <scott-work> ailo: also, i wonder which kernel is being used in lucid these days
[19:05] <scott-work> ailo: if it's 2.6.38 then i might not need to upgrade to natty to test
[19:06] <ailo> scott-work, So far, I have seen no difference in using effects, as long as they don't use all of the CPU, but to find that out, we would need another type of test, I guess
[19:06] <scott-work> i'll check the current kernel in lucid tonight
[19:06] <ailo> scott-work, It's not 2.6.38. And, one part of -generic performance is the actual desktop
[19:06] <scott-work> ah, but i still may upgrade to natty after release
[19:08] <ailo> scott-work, No clue what in the desktop is affecting -generic, but it was clear before that with the same kernel, after an upgrade, the same -generic kernel was not working as well as before. This was when we tested 2.6.38-1
[19:08] <ailo> scott-work, So, we need to test using Natty
[19:09] <scott-work> right, i'm leaning more and more to upgrading natty
[19:09]  * scott-work keeps /home on separate partition
[19:09] <ailo> I suppose we should have been very strict with the actual distro too, so that all tests were done on a fresh install of a certaing release
[19:10] <ailo> The main reason why I don't like -generic is that it changes so much
[19:11] <ailo> One would need to do new tests every one period for many weeks
[19:11] <ailo> To find out exactly how the performance changes
[19:11] <ailo> -lowlatency seems to not change, or not as much
[19:13] <ailo> And, even so, the tests we do, I don't think are really very accurate either
[19:15] <ailo> It would feel better if one test was using the system to the fullest for a full day or more, using one set of settings. I had one xrun yesterday from a pretty leangthy test with -generic. Hard to know if that could happen on -lowlatency too, given some time
[19:15] <scott-work> yeah, like i'm testing on xubuntu instead of ubuntu (but at least it's natty though)
[19:16] <ailo> scott-work, I'm on Ubuntu Studio, but I've installed some extra stuff on one of the machines
[19:16] <scott-work> ailo: i'm less worried about providing critically accurate data, my goal is determine if the -lowlatency provides any benefit
[19:16] <scott-work> and i think broad trends can be shown that support or disprove this
[19:16] <scott-work> so far it appears that the -lowlatency kernel provides some benefit
[19:16] <ailo> scott-work, The more tests we do, the more we'll know, I guess
[19:17] <scott-work> ailo: my plan is to not rely on persia, who has period of absences, i want to begin to forge relations with another (or more) -motu's
[19:18] <scott-work> ailo: as long as i can say, "we tested...here's our data that supports getting -lowlatency into universe" then i think we accomplished our goal
[19:18] <ailo> scott-work, Sounds like a plan
[19:18] <scott-work> you goals may differ, of course :P
[19:18] <scott-work> you may *really* want to understand more about how things affect the kernel
[19:19] <ailo> scott-work, Not really. I just want a kernel that works
[19:19] <ailo> scott-work, If you need to be able to argue for the -lowlatency, I suppose we need some numbers.
[19:22] <ailo> Though, I'm already fairly convinced, that I will never trust -generic, and that -lowlatency is working well on most machines
[19:22] <ailo> I wouldn't trust any kernel, until I tried it myself
[19:23] <ailo> But, I'd rather use -lowlatency than -rt if possible
[19:33] <ailo> scott-work, So, did you have second thoughts about XFCE?
[19:34] <scott-work> ailo: to be completely forthcoming...not really as i think it offers benefits and advantages that i do not believe we will recognize otherwise
[19:34] <scott-work> ailo: but if my perception of unity and gnome3 is wrong i would like to correct it
[19:36] <ailo> scott-work, I don't think using Unity or Gnome3 will be to much advantage in the nearest future, but I'd be surprised if the Desktop system used for audio distros in the future wouldn't be one of those two. Maybe already by the time 12.04 is released.
[19:36] <ailo> Let me rephrase
[19:37] <ailo> I would be surprised if not a lot of people wouldn't prefer using one of those two
[19:38] <ailo> XFCE might present some problems too. I know I had super sized fonts on one laptop, which I didn't get from gnoe
[19:38] <ailo> One font took the space of the whole screen
[19:39] <ailo> Probably very unusual
[19:39] <ailo> Disregarding that XFCE is perhaps less used, I'm sure it is the better choice for now
[19:40] <scott-work> ailo: a large portion of the transition may also depend on what cory can accomplish
[19:41] <ailo> scott-work, Gnome3 new features for 3.2 https://live.gnome.org/ThreePointOne/Features
[19:41] <scott-work> and we are always at liberty to admit a mistake later on and make another transition
[19:42] <ailo> scott-work, Of course
[20:13] <scott-work> ailo a confluence of effects has also changed the way i will oversee ocelot
[20:14] <scott-work> i have also been concerned about how much we talk versus how much we accomplish
[20:14] <scott-work> i think holstein and i had a conversation on this topic
[20:14] <scott-work> probably a large percentage of the blame lies on my shoulders for not taking a stronger stand about direction
[20:15] <scott-work> and i have been giving this some thought for a couple months off and on
[20:16] <scott-work> i think i will look at the list of changes/improvements scheduled for ocelot and attribute direct responsiblities
[20:16] <scott-work> for example, you and paultag might be directly responsible for the -controls udpate
[20:16] <scott-work> i would be responsible for getting -lowlatency into the repositories
[20:17] <scott-work> we can then follow up with progress in meetings and thereby hold people "accountable" for the progress as well :)
[20:18] <scott-work> i imagine there will also be several secondary responsibilities
[20:18] <scott-work> these might include me and you for documentation
[20:18] <scott-work> and that is because i do not expect one person to desire to be dedicated solely to the documentation
[20:19] <scott-work> but if several people have the same secondary responsibility i think significant progress can still occur at a reasonable rate
[20:32] <ailo> scott-work, I'm for that
[20:32] <ailo> scott-work, And I'm willing to take full responsibility for -controls, both coding and packaging, as well as helping out with documentation
[20:33] <scott-work> and hopefully it will also keep people from over committing and focused on something they can effect within a reasonable amount of time
[20:33] <scott-work> that should also keep people feeling like effective and interested
[20:34] <ailo> I think the biggest problem with this release was too few people involved, and lack of knowledge and routine for some, like me
[20:35] <ailo> I'll be feeling much more confident about what I can accomplish for Ocelot
[20:40] <ailo> scott-work, Clear direction is not bad. Some things I feel have higher priority than others. Should we prioritize too?
[20:41] <scott-work> ailo: i think that is a good idea
[23:00] <scott-work> i added ocelot to a ubuntu studio google calender that ricardo setup which also includes meetings
[23:00] <scott-work> if anyone is interested i'll gladly help anyone get it into their calendars
[23:00] <scott-work> but for now, i'm going home