[00:00] <saidinesh5> "VST has now changed to use the Vestige library so there is no longer any reliance on non-free code"
[00:01] <ckontros> ScottL: PM me if needed.
[00:01]  * saidinesh5 still needs a way to test drive US: with no free partitions to spare :-/
[00:01] <saidinesh5> anybody?
[00:02] <persia> You could use the testdrive program.
[00:02]  * saidinesh5 googles
[00:03] <persia> I suspect you'd need to be running some Ubuntu flavour for it to work :)
[00:03] <saidinesh5> i am on kubuntu
[00:03] <saidinesh5> oh you mean like apt-get ubuntu-studio-* ?
[00:05] <persia> No, I mean `apt-get install testdrive`
[00:05] <saidinesh5> ah that uses qemu or something?
[00:05] <persia> File a bug if it doesn't, but it should download an arbitrary image from cdimage.ubuntu.com, and launch that in a virtual machine so you can test it.
[00:06] <persia> By default it tries KVM first: I suspect it falls back to virtualbox, and only then to qemu (but I'm not sure)
[00:06] <saidinesh5> last time when i used virtual box
[00:06] <saidinesh5> it was as laggy as hell
[00:06] <saidinesh5> :-/
[00:07] <persia> I can't seem to find good information about VeSTige: just reviews.
[00:07]  * saidinesh5 checks his history
[00:07] <persia> It may or may not be OK: I did encounter a discussion where people disagreed.
[00:09] <persia> (something about whether the developers had access to the VST SDK while constructing VeSTige, or whether they were working from a sufficiently "obvious" basis: of course this isn't decideable except by a court, but if there is consensus, nobody will go to court, so the consensus must be right)
[00:09] <saidinesh5> oh
[00:11] <saidinesh5> ya most programs come with 
[00:11] <saidinesh5> a " donot reverse engineer " agreement
[00:11] <persia> Right.  If someone violates that, then the material they release is tainted, so other folk can't safely use it.
[00:12] <saidinesh5> yaa
[00:12] <persia> Sorting VST is annoying and painful.  The first VST patents will expire in 2013, and so someone can go read them, and then write code based on them, and ship it.
[00:12] <saidinesh5> wow
[00:12] <saidinesh5> thats still hope ful :)
[00:13] <saidinesh5> the problem is its a widely used standard
[00:13] <saidinesh5> i was hoping android would change the situation at least a little bit
[00:13] <persia> But before that, it requires agreement with Steinberg, or some other way around the issues.  Note also that as the specification keeps being updated, getting full support won't happen until either the *last* patent expires (currently something like 2028), or someone has an agreement with Steinberg.
[00:13] <saidinesh5> (actually meego but wth!)
[00:14] <persia> That makes no difference.  Steinberg could release "Cubase for Ubuntu", and it wouldn't solve the problem.
[00:14] <persia> (well, people could run VSTs in "Cubase for Ubuntu", but we'd still have issues running them in Ardour without hackery)
[00:14] <saidinesh5> but it would solve a lot of other problems
[00:15] <saidinesh5> like no more wine for a lot of VSTs
[00:15] <saidinesh5> and basically its almost like the case with GIMP and others vs. Adobe
[00:16] <persia> No, it wouldn't help with the Windows Dependency at all: that's a different issue.  "Cubase for Ubuntu" would probably recommend installing WINE so that one could run VSTs that weren't linux-native.
[00:16] <saidinesh5> WINE is too laggy for VSTs
[00:17] <saidinesh5> the little ones *might* run ...
[00:17] <saidinesh5>  but the good ones definitely won
[00:17] <saidinesh5> *wont
[00:18] <saidinesh5> persia: i ll soon be buying a keyboard too... so do we have any good hardware database saying this works and this doesnt??
[00:19] <ailo_> saidinesh5, usb keyboard?
[00:19] <saidinesh5> well at least the midi interfacing 
[00:19] <saidinesh5> should be done via. USB
[00:20] <ailo_> saidinesh5, I know that any standard compliant keyboard will work, which I believe are most keyboards out there. But, when it comes to performance, I don't have any good knowledge about that
[00:20] <persia> Any "Class-complaint" USB keyboard works.  Anything else is going to cause trouble for *every* operating system.  The manufacturers are proud when they have "Class-complaint" devices, and advertise that.
[00:20] <saidinesh5> Oh i see
[00:21] <ailo_> ralph on the mail list could probably tell us some more about midi hardware and performance
[00:21] <ailo_> At least on the performance bit
[00:21] <saidinesh5> well i wouldn't want to buy something like my NVIDIA card for my laptop
[00:21] <saidinesh5> bad bad drivers and stuff
[00:21] <persia> There's not much difference in "performance" between the MIDI Master keyboards: choose one by how it feels.
[00:21] <saidinesh5> oh... i see
[00:21] <ailo_> persia, I'm just thinking about midi jitter, pci vs usb
[00:22] <ailo_> I really don't have any experience myself in time accurate midi usage
[00:22] <persia> ailo_, Makes no difference: most of those issues have to with MIDI controllers.  That said, MIDI is a *very* low bandwidth protocol: USB can more than handle it (even USB 1.1)
[00:23] <saidinesh5> even bluetooth can handle MIDI
[00:23]  * ScottL is catching up on backscroll
[00:23] <saidinesh5> i m not going to need it for any live performances, so time accuracy shouldnt be a problem
[00:24] <persia> 8 voices at 256bpm with automation on *every* note is something like 300 bytes/second.
[00:25] <saidinesh5> hmm... ya
[00:26] <persia> Anyway, selecting interfaces, keyboards, etc. is better discussed on #ubuntustudio
[00:26] <saidinesh5> hmm...... k ....... as soon as will short list my keyboard will bring this up :)
[00:57] <ScottL> saidinesh5, also you can talk to people on #opensourcemusicians, there are a lot of knowledgeable people there who are familiar with crazy, mad amounts of things
[00:57] <saidinesh5> wow thanks ScottL for this channel!!
[00:58] <saidinesh5>  i was always looking for one such one!
[01:07]  * saidinesh5 hits the bed now: *THUD* ........ gNite/Day folks :)
[03:19] <ScottL> persia, after reading through the literature about delegated teams and package set, i don't see any immediate obstacle in asking for the ubuntustudio-dev team to be approved
[03:19] <ScottL> do you?
[03:19] <ScottL> i realize we need to make a wiki page still
[03:19] <ScottL> i get that _would_ be an immediate obstacle
[04:03] <ScottL> s/get/guess
[04:03] <ScottL> although i suppose it's not really an obstacle as much as it is a task
[05:02] <Kokito> good evening folks
[05:09] <ScottL> hi kok
[05:09] <ScottL> Kokito, 
[05:10] <Kokito> hey ScottL :)
[09:06] <persia> ScottL, I know of no obstacles.  We have a package set, based on the seed (because the release team needed it to track freeze exceptions).
[09:07] <persia> I don't believe we have sufficient activity and organisation to request to be a delegated team, but I do think we ought have a development team.
[09:08] <persia> (if the distinction isn't clear, let me know, and I'll try to clean up the docs again)
[09:08] <persia> Once we have a development team, there are a few folks who we should push to be part of that team, to smooth operations :)
[13:20] <ScottL> persia, i will reread the documentation because i am unclear
[13:21] <persia> ScottL, OK, but I suspect the chances that I wrote it confusingly are higher than the chances that you're incapable of understanding it.
[14:36] <ScottL> persia, i am still unclear, is there another link i can read?
[14:38] <ScottL> i am also working with david h. to get pulse audio and jack to working nicely together and it *just doesn't seem to want to*
[14:39] <ScottL> i'm a little concerned because i'm beginning to worry that either david isn't as knowledgeable as i thought or ubuntu studio's setup is drastically different than ubuntu
[17:33] <persia> ScottL, OK.  For packagesets/development teams: what isn't clear?  What questions do you have?
[17:33] <persia> For pulse/JACK, I expect your largest issue is that you have multiple cards, although I may be mistaken.