From jens.andreasen at chello.se Sat Jul 1 02:22:16 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Jul 1 02:22:23 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060630210440.GB25650@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> <20060630210440.GB25650@fitz.Belkin> Message-ID: <1151734936.9274.331.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2006-06-30 at 22:04 +0100, james@dis-dot-dat.net wrote: > Wow. > > I just have linear ADSR, which is about all I need. The exponential > decay and attack are probably a good idea, though. > Linear attack sounds OK. Given the exponential way we perceive volume, this *is* the desired function. Linear decay is probably not so good. That would leave the sound sneakily hanging around untill it, for no apparent reason, suddenly disappears. From fons.adriaensen at skynet.be Sat Jul 1 08:09:02 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sat Jul 1 08:08:47 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <1151734936.9274.331.camel@c80-216-124-251.cm-upc.chello.se> References: <20060629123800.GM10261@fitz.Belkin> <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> <20060630210440.GB25650@fitz.Belkin> <1151734936.9274.331.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060701120902.GA5951@linux-1.site> On Sat, Jul 01, 2006 at 08:22:16AM +0200, Jens M Andreasen wrote: > Linear attack sounds OK. Given the exponential way we perceive volume, > this *is* the desired function. That's the rationale for having exponential volume controls. In the case of a release profile, it's rather because many real sounds produced by resonating physical things (so-called intruments :-) die out exponentially. But that is only the simplest case. Once you couple e.g. a string to a soundboard, what you get is usually a sum of exponentials with different time constants. AMS has a module that emulates this. A good way to produce natural sounding envelopes is not the 'construct' the envelope, but to see it as the output of a filter operating on a trigger or gate signal. -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Sat Jul 1 10:42:49 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 10:42:54 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630145452.GD13275@teasel.arb.net> References: <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> Message-ID: <1151764969.19306.0.camel@localhost.localdomain> On Fri, 2006-06-30 at 15:54 +0100, Robert Ham wrote: > On Fri, Jun 30, 2006 at 10:25:04AM -0400, Forest Bond wrote: > > > As far as I can tell there are two resolutions: > > > > 1) someone works on fst to make it save kontakt's state > > 2) someone writes a free kontakt replacement > > 3) someone makes Linux Sampler do what Kontakt does LinuxSampler is not free software or open source software. -DR- From luisgarrido at users.sourceforge.net Sat Jul 1 11:43:42 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Jul 1 11:43:46 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151764969.19306.0.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: > LinuxSampler is not free software or open source software. > (sigh, must we, really?) It depends on who you choose to side with. As defined by the FSF, no, it is not free software. If you use the freebeerian definition, "you don't have to pay its authors to use it", yes, it is. As defined by the OSI it is not open source, either: http://en.wikipedia.org/wiki/Open_Source_Definition According to other definitions by the Wikipedia it is very much indeed open source: http://en.wikipedia.org/wiki/Open_source http://en.wikipedia.org/wiki/Open_source_license http://en.wikipedia.org/wiki/Open_source_vs._free_software OTOH rumour has it that this may change, not sure in which direction, so it may be healthy to be cautious. In the end, there is always the possibility of forking version 0.3.3 which is pure GPL and call it HurdSoftSampler or SuftSampler (pun intended) or something like that XD Anyway, the rationale behind this restriction is quite understandable: the guys are afraid that a third party could make a commercial profit of their work without giving anything back to the OS community. It has happened before to other projects. http://sourceforge.net/mailarchive/message.php?msg_id=12912656 Peace, Luis From lars.luthman at gmail.com Sat Jul 1 12:09:23 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jul 1 12:09:34 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: <1151770164.7567.0.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > OTOH rumour has it that this may change, not sure in which direction, > so it may be healthy to be cautious. In the end, there is always the > possibility of forking version 0.3.3 which is pure GPL and call it > HurdSoftSampler or SuftSampler (pun intended) or something like that > XD I don't get the pun... -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060701/046ac3b2/attachment.bin From rlrevell at joe-job.com Sat Jul 1 12:22:16 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Jul 1 12:22:05 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: <1151770937.12026.4.camel@mindpipe> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > As defined by the FSF, no, it is not free software. If you use the > freebeerian definition, "you don't have to pay its authors to use it", > yes, it is. > In the Linux world "free software" means free as in speech. No one uses "free software" to refer to closed source software that's given away for free. Lee From drobilla at connect.carleton.ca Sat Jul 1 12:34:26 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 12:34:31 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: <1151771666.19306.4.camel@localhost.localdomain> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > > LinuxSampler is not free software or open source software. > > > > (sigh, must we, really?) > > It depends on who you choose to side with. Forget "free software" then, I don't mean to start any debate, and there's no "sides" here. Just that people are talking about writing open source alternatives to things (Kontakt) and referring to LinuxSampler as the project to do so, so it should be pointed out so people aren't misled. LinuxSampler is not open source. -DR- From pshirkey at boosthardware.com Sat Jul 1 12:53:21 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Jul 1 12:54:37 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151771666.19306.4.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> Message-ID: <44A6A881.8010902@boosthardware.com> Dave Robillard wrote: > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: >>> LinuxSampler is not free software or open source software. >>> >> (sigh, must we, really?) >> >> It depends on who you choose to side with. > > Forget "free software" then, I don't mean to start any debate, and > there's no "sides" here. Just that people are talking about writing > open source alternatives to things (Kontakt) and referring to > LinuxSampler as the project to do so, so it should be pointed out so > people aren't misled. > > LinuxSampler is not open source. > It's veeeery close though. It's just using a modified GPL License which isn't clearly labelled as such. IANAL but that makes LinuxSampler illegally licensed if someone wanted to make a fuss about it. They call it GPL version 2 or 3 but it has been modified so that nullifies it AFAIK. If they don't fix it and someone does use their software to make a financial gain then it could very easily be argued that the software is licensed as GPL 2 or 3 and that makes it 100% open source. It's good to know that the core team are reviewing the current license as it would no doubt be messy for them to get caught short. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From lars.luthman at gmail.com Sat Jul 1 13:22:49 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jul 1 13:22:56 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6A881.8010902@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> Message-ID: <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > Dave Robillard wrote: > > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > >>> LinuxSampler is not free software or open source software. > >>> > >> (sigh, must we, really?) > >> > >> It depends on who you choose to side with. > > > > Forget "free software" then, I don't mean to start any debate, and > > there's no "sides" here. Just that people are talking about writing > > open source alternatives to things (Kontakt) and referring to > > LinuxSampler as the project to do so, so it should be pointed out so > > people aren't misled. > > > > LinuxSampler is not open source. > > > > It's veeeery close though. > > It's just using a modified GPL License which isn't clearly labelled as > such. IANAL but that makes LinuxSampler illegally licensed if someone > wanted to make a fuss about it. They call it GPL version 2 or 3 but it > has been modified so that nullifies it AFAIK. If they don't fix it and > someone does use their software to make a financial gain then it could > very easily be argued that the software is licensed as GPL 2 or 3 and > that makes it 100% open source. I don't think so. If the GPL is combined with some other license agreement or restriction that is not compatible with the GPL, it automatically cancels itself (see paragraph 7, http://www.gnu.org/licenses/gpl.txt ) and normal copyright law applies. Which in most countries means that only the actual copyright owner (if there is a single one) is allowed to distribute it. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060701/513f23a5/attachment.bin From pshirkey at boosthardware.com Sat Jul 1 13:41:06 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Jul 1 13:42:16 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <44A6B3B2.3060408@boosthardware.com> Lars Luthman wrote: > On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: >> Dave Robillard wrote: >>> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: >>>>> LinuxSampler is not free software or open source software. >>>>> >>>> (sigh, must we, really?) >>>> >>>> It depends on who you choose to side with. >>> Forget "free software" then, I don't mean to start any debate, and >>> there's no "sides" here. Just that people are talking about writing >>> open source alternatives to things (Kontakt) and referring to >>> LinuxSampler as the project to do so, so it should be pointed out so >>> people aren't misled. >>> >>> LinuxSampler is not open source. >>> >> It's veeeery close though. >> >> It's just using a modified GPL License which isn't clearly labelled as >> such. IANAL but that makes LinuxSampler illegally licensed if someone >> wanted to make a fuss about it. They call it GPL version 2 or 3 but it >> has been modified so that nullifies it AFAIK. If they don't fix it and >> someone does use their software to make a financial gain then it could >> very easily be argued that the software is licensed as GPL 2 or 3 and >> that makes it 100% open source. > > I don't think so. If the GPL is combined with some other license > agreement or restriction that is not compatible with the GPL, it > automatically cancels itself (see paragraph 7, > http://www.gnu.org/licenses/gpl.txt ) and normal copyright law applies. > Which in most countries means that only the actual copyright owner (if > there is a single one) is allowed to distribute it. > So then it is definitely not open source due to the current license. I hope they fix it soon. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From drobilla at connect.carleton.ca Sat Jul 1 14:59:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 14:59:43 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6B3B2.3060408@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> Message-ID: <1151780378.19306.9.camel@localhost.localdomain> On Sun, 2006-07-02 at 00:41 +0700, Patrick Shirkey wrote: > Lars Luthman wrote: > > On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > >> Dave Robillard wrote: > >>> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > >>>>> LinuxSampler is not free software or open source software. > >>>>> > >>>> (sigh, must we, really?) > >>>> > >>>> It depends on who you choose to side with. > >>> Forget "free software" then, I don't mean to start any debate, and > >>> there's no "sides" here. Just that people are talking about writing > >>> open source alternatives to things (Kontakt) and referring to > >>> LinuxSampler as the project to do so, so it should be pointed out so > >>> people aren't misled. > >>> > >>> LinuxSampler is not open source. > >>> > >> It's veeeery close though. > >> > >> It's just using a modified GPL License which isn't clearly labelled as > >> such. IANAL but that makes LinuxSampler illegally licensed if someone > >> wanted to make a fuss about it. They call it GPL version 2 or 3 but it > >> has been modified so that nullifies it AFAIK. If they don't fix it and > >> someone does use their software to make a financial gain then it could > >> very easily be argued that the software is licensed as GPL 2 or 3 and > >> that makes it 100% open source. > > > > I don't think so. If the GPL is combined with some other license > > agreement or restriction that is not compatible with the GPL, it > > automatically cancels itself (see paragraph 7, > > http://www.gnu.org/licenses/gpl.txt ) and normal copyright law applies. > > Which in most countries means that only the actual copyright owner (if > > there is a single one) is allowed to distribute it. > > > > So then it is definitely not open source due to the current license. > > I hope they fix it soon. Indeed. A sampler you can't even use on an album you intend to sell or in a performance you sell tickets to isn't exactly the most useful thing in the world. -DR- From drobilla at connect.carleton.ca Sat Jul 1 15:08:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 15:08:44 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630003707.GE20075@storm.local.network> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> Message-ID: <1151780918.19306.17.camel@localhost.localdomain> On Thu, 2006-06-29 at 20:37 -0400, Forest Bond wrote: > Thanks for clarifying the licensing issues. I think I knew that at some point. > > What are the odds of changing the FST license to GPL-with-exceptions? As mentioned earlier, this would also violate the GPL license of LASH, which I am a partial copyright holder to, and while (as mentioned in the tarball in the spirit of Bob who came before me) I'm open to license changes with good reason, I will not grant such an exception for this case. Sorry. The VST license is what needs fixing, not ours. -DR- From rah at bash.sh Sat Jul 1 15:33:10 2006 From: rah at bash.sh (Bob Ham) Date: Sat Jul 1 15:33:23 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6A881.8010902@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> Message-ID: <1151782390.30130.7.camel@orchid.arb.net> On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > Dave Robillard wrote: > > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > >>> LinuxSampler is not free software or open source software. > >>> > >> (sigh, must we, really?) > >> > >> It depends on who you choose to side with. > > It's just using a modified GPL License which isn't clearly labelled as > such. According to this URL http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/Sampler.cpp?rev=1.28&content-type=text/vnd.viewcvs-markup I have permission to use that particular file under the GPL, or (at my option) any later version. Looking through a few other files and I see I have the same permissions for those. Seems to be open source *and* free software *and* released under the GPL *and* free-as-in-beer. *shrug* Bob -- Bob Ham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060701/a74e2f17/attachment.bin From drobilla at connect.carleton.ca Sat Jul 1 15:51:48 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 15:51:52 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151782390.30130.7.camel@orchid.arb.net> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151782390.30130.7.camel@orchid.arb.net> Message-ID: <1151783508.19306.20.camel@localhost.localdomain> On Sat, 2006-07-01 at 20:33 +0100, Bob Ham wrote: > On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > > Dave Robillard wrote: > > > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > > >>> LinuxSampler is not free software or open source software. > > >>> > > >> (sigh, must we, really?) > > >> > > >> It depends on who you choose to side with. > > > > It's just using a modified GPL License which isn't clearly labelled as > > such. > > According to this URL > > http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/Sampler.cpp?rev=1.28&content-type=text/vnd.viewcvs-markup > > I have permission to use that particular file under the GPL, or (at my > option) any later version. Looking through a few other files and I see > I have the same permissions for those. Seems to be open source *and* > free software *and* released under the GPL *and* free-as-in-beer. > > *shrug* Definitely, at the end of the day there is no way in hell their "exception" would hold up in court, since they basically just mention it in passing on the web page. Regardless of what way the license goes, it definitely needs to be clarified. -DR- From rncbc at rncbc.org Sat Jul 1 15:56:19 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sat Jul 1 15:57:05 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6B3B2.3060408@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> Message-ID: <44A6D363.8020207@rncbc.org> Patrick Shirkey wrote: > Lars Luthman wrote: >> On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: >>> Dave Robillard wrote: >>>> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: >>>>>> LinuxSampler is not free software or open source software. >>>>>> >>>>> (sigh, must we, really?) >>>>> >>>>> It depends on who you choose to side with. >>>> Forget "free software" then, I don't mean to start any debate, and >>>> there's no "sides" here. Just that people are talking about writing >>>> open source alternatives to things (Kontakt) and referring to >>>> LinuxSampler as the project to do so, so it should be pointed out so >>>> people aren't misled. >>>> >>>> LinuxSampler is not open source. >>>> >>> It's veeeery close though. >>> >>> It's just using a modified GPL License which isn't clearly labelled >>> as such. IANAL but that makes LinuxSampler illegally licensed if >>> someone wanted to make a fuss about it. They call it GPL version 2 or >>> 3 but it has been modified so that nullifies it AFAIK. If they don't >>> fix it and someone does use their software to make a financial gain >>> then it could very easily be argued that the software is licensed as >>> GPL 2 or 3 and that makes it 100% open source. >> >> I don't think so. If the GPL is combined with some other license >> agreement or restriction that is not compatible with the GPL, it >> automatically cancels itself (see paragraph 7, >> http://www.gnu.org/licenses/gpl.txt ) and normal copyright law applies. >> Which in most countries means that only the actual copyright owner (if >> there is a single one) is allowed to distribute it. > > So then it is definitely not open source due to the current license. > When did it happen that when some software project is not GPL is not open-source? E.g. apache is not GPL, so it must not be open-source? Problem with linuxsampler license void its all about that infamous exception clause on the README file, "that it may NOT be used in COMMERCIAL software or hardware products without prior written authorization by the authors." Beside the simple fact that it voids the GPL, it certainly doesn't make it closed-source nor proprietary. Meanwhile, development has been carried on as open-source, normally as ever someone noticed that damn clause and flamed about it. > I hope they fix it soon. > Rumors are that it will be plain GPL as it was intended from the beginning, with that exception being just ditched. In fact, the exception was there all the time, even I didn't notice it for years :) OTOH, linuxsampler is still an unfinished project and still in development and yes, under an open-source fashion, thank you. Bye now. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From drobilla at connect.carleton.ca Sat Jul 1 16:09:42 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 16:09:49 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6D363.8020207@rncbc.org> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> Message-ID: <1151784582.19306.23.camel@localhost.localdomain> On Sat, 2006-07-01 at 20:56 +0100, Rui Nuno Capela wrote: > Patrick Shirkey wrote: > > Lars Luthman wrote: > >> On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > >>> Dave Robillard wrote: > >>>> On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > >>>>>> LinuxSampler is not free software or open source software. > >>>>>> > >>>>> (sigh, must we, really?) > >>>>> > >>>>> It depends on who you choose to side with. > >>>> Forget "free software" then, I don't mean to start any debate, and > >>>> there's no "sides" here. Just that people are talking about writing > >>>> open source alternatives to things (Kontakt) and referring to > >>>> LinuxSampler as the project to do so, so it should be pointed out so > >>>> people aren't misled. > >>>> > >>>> LinuxSampler is not open source. > >>>> > >>> It's veeeery close though. > >>> > >>> It's just using a modified GPL License which isn't clearly labelled > >>> as such. IANAL but that makes LinuxSampler illegally licensed if > >>> someone wanted to make a fuss about it. They call it GPL version 2 or > >>> 3 but it has been modified so that nullifies it AFAIK. If they don't > >>> fix it and someone does use their software to make a financial gain > >>> then it could very easily be argued that the software is licensed as > >>> GPL 2 or 3 and that makes it 100% open source. > >> > >> I don't think so. If the GPL is combined with some other license > >> agreement or restriction that is not compatible with the GPL, it > >> automatically cancels itself (see paragraph 7, > >> http://www.gnu.org/licenses/gpl.txt ) and normal copyright law applies. > >> Which in most countries means that only the actual copyright owner (if > >> there is a single one) is allowed to distribute it. > > > > So then it is definitely not open source due to the current license. > > > > When did it happen that when some software project is not GPL is not > open-source? E.g. apache is not GPL, so it must not be open-source? Noone said that. > Problem with linuxsampler license void its all about that infamous > exception clause on the README file, "that it may NOT be used in > COMMERCIAL software or hardware products without prior written > authorization by the authors." > > Beside the simple fact that it voids the GPL, it certainly doesn't make > it closed-source Actually yes it does, by the "official" open source definition (which is clearly what people refer to when they use the term "open source". http://www.opensource.org/docs/definition.php Whether or not you agree with the licensing practise, calling it "open source" is as misleading as calling MS shared source "open source". Defend the license/exception if you want, but don't intentionally mislead people about the licensing terms. -DR- From luisgarrido at users.sourceforge.net Sat Jul 1 17:17:13 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Jul 1 17:17:17 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151780378.19306.9.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <1151780378.19306.9.camel@localhost.localdomain> Message-ID: > Indeed. A sampler you can't even use on an album you intend to sell or > in a performance you sell tickets to isn't exactly the most useful thing > in the world. > While the LS license wording undoubtedly admits your interpretation: "LinuxSampler is licensed under the GNU GPL license with the exception that COMMERCIAL USE of the souce code, libraries and applications is NOT ALLOWED without prior written permission by the LinuxSampler authors." I think they are referring to other kind of commercial use. As taken from the FAQ: "You are NOT ALLOWED to use LinuxSampler source code, libraries or applications in COMMERCIAL hardware or software products without prior written authorization by the authors." Probably they had in mind something like Oasys, which is based on Linux http://www.korg.com/gear/prod_info.asp?A_PROD_NO=OASYS and don't want their work to become part of a big company product without having the OSS community getting something in return. But, yeah, that clause is a royal mess and it needs to be clarified. Legalese apart, since I don't plan to sell it or to produce a platinum album, it seems to me quite open and free, even if it is not Open(tm) and Free(tm) (it would seem that the words "Open Source" are not open source, anymore, how cool is that?) At the very least I can learn a lot from the available source code, I can tweak it to my needs and I can enjoy the sounds it makes in non commercial situations (and probably in commercial ones if I understood the intentions of the authors, but I wouldn't risk it without a clearer wording of the clause in question.) And as I said before, LS 0.3.3 _is_ 100% GPL, only the CVS version is subjected to this licensing. Luis From fons.adriaensen at skynet.be Sat Jul 1 18:43:06 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sat Jul 1 18:42:44 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151784582.19306.23.camel@localhost.localdomain> References: <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> Message-ID: <20060701224306.GA5933@linux-1.site> On Sat, Jul 01, 2006 at 04:09:42PM -0400, Dave Robillard wrote: > Whether or not you agree with the licensing practise, calling it "open > source" is as misleading as calling MS shared source "open source". > Defend the license/exception if you want, but don't intentionally > mislead people about the licensing terms. If the source is available for everyone to read, then it is open according to the normal meaning of those words in English. What is misleading is to attach any other meaning to them. It's a typical marketeer's trick to redefine words or concepts that have a clear an established meaning, and IMHO that's a disgusting practice. Besides that, DR is broadcasting plain lies. There is nothing in the Linuxsampler licence nor in that infamouse README that should impede you using it for an album or concert you sell commercially. -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Sat Jul 1 19:43:56 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 1 19:44:13 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060701224306.GA5933@linux-1.site> References: <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> <20060701224306.GA5933@linux-1.site> Message-ID: <1151797436.19306.38.camel@localhost.localdomain> On Sun, 2006-07-02 at 00:43 +0200, Fons Adriaensen wrote: > On Sat, Jul 01, 2006 at 04:09:42PM -0400, Dave Robillard wrote: > > > Whether or not you agree with the licensing practise, calling it "open > > source" is as misleading as calling MS shared source "open source". > > Defend the license/exception if you want, but don't intentionally > > mislead people about the licensing terms. > > If the source is available for everyone to read, then it is open > according to the normal meaning of those words in English. What is > misleading is to attach any other meaning to them. It's a typical > marketeer's trick to redefine words or concepts that have a clear > an established meaning, and IMHO that's a disgusting practice. Give me a break, you and I and everyone else on this list know what "open source" means. > Besides that, DR is broadcasting plain lies. There is nothing in > the Linuxsampler licence nor in that infamouse README that should > impede you using it for an album or concert you sell commercially. Did you even look at the webpage before deciding to troll me this pathetically? Creating something to sell is obviously "commercial use". Duh. Redefine "open source" all you like, LS is not "open source" by the almost universally accepted definition of that term (the OSI one). That's the point I wished to make, it is an irrefutable fact, and it's been made, so I'm done with this conversation. -DR- From lars.luthman at gmail.com Sat Jul 1 19:44:39 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jul 1 19:45:11 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060701224306.GA5933@linux-1.site> References: <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> <20060701224306.GA5933@linux-1.site> Message-ID: <1151797481.7567.21.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-02 at 00:43 +0200, Fons Adriaensen wrote: > On Sat, Jul 01, 2006 at 04:09:42PM -0400, Dave Robillard wrote: > > > Whether or not you agree with the licensing practise, calling it "open > > source" is as misleading as calling MS shared source "open source". > > Defend the license/exception if you want, but don't intentionally > > mislead people about the licensing terms. > > If the source is available for everyone to read, then it is open > according to the normal meaning of those words in English. What is > misleading is to attach any other meaning to them. It's a typical > marketeer's trick to redefine words or concepts that have a clear > an established meaning, and IMHO that's a disgusting practice. Come on, I think an overwhelming majority of the readers of this list interprets "open source" or "free software" as "software for which I can get the source and modify and redistribute (including for commercial purposes)" instead of "software for which I can read the source" or "software for which I don't have to pay anything". People use old words and phrases to mean new things all the time, mostly because describing the new thing exactly would be too long and making up a completely new word would just sound silly. > Besides that, DR is broadcasting plain lies. There is nothing in > the Linuxsampler licence nor in that infamouse README that should > impede you using it for an album or concert you sell commercially. A notice on the "Download" webpage on http://www.linuxsampler.org says LinuxSampler is licensed under the GNU GPL license with the exception that COMMERCIAL USE of the source code, libraries and applications is NOT ALLOWED without prior written permission by the LinuxSampler authors. I would definitely say that using linuxsampler to produce an album that you are selling or to perform a live concert to which you sell tickets falls under "commercial use of the application". That is probably not what the authors meant, but it's the natural way to interpret it. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060702/da0d3fea/attachment.bin From ryan at ryanheise.com Sat Jul 1 23:47:04 2006 From: ryan at ryanheise.com (Ryan Heise) Date: Sat Jul 1 23:47:16 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060701224306.GA5933@linux-1.site>; from fons.adriaensen@skynet.be on Sun, Jul 02, 2006 at 12:43:06AM +0200 References: <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> <20060701224306.GA5933@linux-1.site> Message-ID: <20060702134704.A21411@linus.it.uts.EDU.AU> On Sun, Jul 02, 2006 at 12:43:06AM +0200, Fons Adriaensen wrote: > On Sat, Jul 01, 2006 at 04:09:42PM -0400, Dave Robillard wrote: > > > Whether or not you agree with the licensing practise, calling it "open > > source" is as misleading as calling MS shared source "open source". > > Defend the license/exception if you want, but don't intentionally > > mislead people about the licensing terms. > > If the source is available for everyone to read, then it is open > according to the normal meaning of those words in English. What is > misleading is to attach any other meaning to them. It's a typical > marketeer's trick to redefine words or concepts that have a clear > an established meaning, and IMHO that's a disgusting practice. Hi, I'm new to this list so please be gentle :-) (not you specifically, but I am aware that I'm about to step into the middle of a debate that has already become heated :-) Here are my thoughts... I think most concepts/products/software/phenomena etc. have names that are derived from common English words that have a common meanings. Like "LinuxSampler". This is a new term derived from existing words with common meanings. * However, note that while the intended meaning of "sampler" in this context is common, it is not the only common meaning of "sampler". - Out of respect to the person (or people) who coined the term "LinuxSampler", we recognise that as a new term, regardless of what other meanings the original words may have had. - Out of respect to everyone else, I'm sure the person (or people) who coin a new term try to use a distinctive combination of words that is not already in common use. New terms are almost always derived from existing words, and almost always take on meanings of their own, and it is pretty much difficult to find otherways of naming things, like inventing entirely new, and therefore strange-sounding, words. The term "open source" was a new term, coined in 1998, that was not previously in wide usage, hence passed the test of not choosing a combination of words that someone else had already found. Now that the term has been coined and become widely adopted for its particular meaning, we can respect it as a term in itself. One way to disrespect the term is: after the new term has become established with its new particular meaning, then claim it with different meanings. I think it happens to be easier to defend the OSI's term "open source" than it is to defend the FSF's term "free software", although I respect both terms. The term "open source" prior to 1998 was not in common use at all and only after OSI's "open source" term was coined did it become widely used and understood. Also, grammatically, "open source" might possibly be seen more clearly as a term, rather than just two words with their original meaning, because it is missing the hyphen, which would normally be there if they were just two ordinary words in a sentence. "Free software", on the other hand, has no grammatical hints to indicate that this is a special term, and it *is* possible to use those two words in a sentence without indicating the meaning assigned by the FSF. However, as Lee pointed out, in Linux circles, the meaning of "free software" should be clear, partly because Linux, and a very significant portion of software that normally runs on it (and which Linux depends on) are based on a license published by the FSF. In other words, Linux has its roots in circles where the meaning of "free software" is understood to be that initiated by RMS when he started the "free software movement" (even though Linux itself doesn't necessarily belong to that movement). Probably more obvious is that Linuxsampler's license gives the FSF's definition of "free software", and so that is the definition that should be assumed in a thread about Linuxsampler :-) > Besides that, DR is broadcasting plain lies. There is nothing in > the Linuxsampler licence nor in that infamouse README that should > impede you using it for an album or concert you sell commercially. I am not a Lawyer, but adding exceptions to the GPL is a tricky business since the way the exceptions interact with the rest of the license is not always clear. If Bob is correct, Linuxsampler has already made an error in forgetting (or maybe not?) to add the same exception to the notices on individual files within the project. -- Ryan Heise http://www.ryanheise.com/ From t_w_ at freenet.de Sun Jul 2 04:49:54 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sun Jul 2 04:50:06 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060701224306.GA5933@linux-1.site> References: <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> <20060701224306.GA5933@linux-1.site> Message-ID: <20060702084954.GA7322@charly.SWORD> On Sun, Jul 02, 2006 at 12:43:06AM +0200, Fons Adriaensen wrote: > > Besides that, DR is broadcasting plain lies. There is nothing in > the Linuxsampler licence nor in that infamouse README that should > impede you using it for an album or concert you sell commercially. He's 'broadcasting' the only valid interpretation of that infamous exception. So it isn't meant that way, but it's not what it says. Commercial use is a very broad term. To me your behaviour of accusing Dave of plain lying is not acceptable. You seem to implicate dishonesty. I'm disgusted. -- Thorsten Wilms From mobarre at gmail.com Sun Jul 2 05:27:16 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Sun Jul 2 05:27:29 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A6D363.8020207@rncbc.org> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> Message-ID: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> Hi all, > Problem with linuxsampler license void its all about that infamous > exception clause on the README file, "that it may NOT be used in > COMMERCIAL software or hardware products without prior written > authorization by the authors." I find this thread very interesting, and I'd like to add a real life situation to it since we also seem to have linuxsampler devs following this. I play in band called Kinoko en Orbite. I'll spare you with the translation/explaination, it's not the point. My home studio is built with free/opensource/GPLed/whatever-you-call-it software and I intend to use my studio to make a record for my band. I also plan to actually use a lot of these same softwares on stage. In other words, I intend to make a commercial usage of linuxsampler since we'll get money in exchange of these CDs (through it will alo be available on jamendo.org), and we intend to make people pay for these concerts. Can I use linuxsampler for this purpose since according to the license I need to ask ? Could the situation be clarified at least for musicians like me who do not intend to build hardware, but who want to earn a living playing music with your software ? My live sessions in Paris are starting soon, and I plan to spend my summer recording with my band. This is something I need to know. _________________ Marc-Olivier Barre, Kinoko en Orbite. From fons.adriaensen at skynet.be Sun Jul 2 06:52:32 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sun Jul 2 06:52:19 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060702084954.GA7322@charly.SWORD> References: <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <1151784582.19306.23.camel@localhost.localdomain> <20060701224306.GA5933@linux-1.site> <20060702084954.GA7322@charly.SWORD> Message-ID: <20060702105232.GB5972@linux-1.site> On Sun, Jul 02, 2006 at 10:49:54AM +0200, Thorsten Wilms wrote: > To me your behaviour of accusing Dave of plain lying is not > acceptable. You seem to implicate dishonesty. I someone states as a fact and without any qualification a certain interpretation of a text, while knowing very well that this interpretation is not what the authors of that text meant to say, that _is_ IMHO intellectual dishonesty. > I'm disgusted. As I was after reading the statement I refer to. I do agree that the text in LS's README is very badly written, and this *is* a problem. The only way to get it changed is to point this out the authors. Nothing useful will result from deliberately misunderstanding it or from vilifying them. -- FA Follie! Follie! Delirio vano e' questo! From rncbc at rncbc.org Sun Jul 2 07:36:43 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sun Jul 2 07:37:29 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> Message-ID: <44A7AFCB.2020505@rncbc.org> Marc-Olivier Barre wrote: > Hi all, > >> Problem with linuxsampler license void its all about that infamous >> exception clause on the README file, "that it may NOT be used in >> COMMERCIAL software or hardware products without prior written >> authorization by the authors." > > I find this thread very interesting, and I'd like to add a real life > situation to it since we also seem to have linuxsampler devs following > this. > > I play in band called Kinoko en Orbite. I'll spare you with the > translation/explaination, it's not the point. > > My home studio is built with > free/opensource/GPLed/whatever-you-call-it software and I intend to > use my studio to make a record for my band. I also plan to actually > use a lot of these same softwares on stage. In other words, I intend > to make a commercial usage of linuxsampler since we'll get money in > exchange of these CDs (through it will alo be available on > jamendo.org), and we intend to make people pay for these concerts. > > Can I use linuxsampler for this purpose since according to the license > I need to ask ? > > Could the situation be clarified at least for musicians like me who do > not intend to build hardware, but who want to earn a living playing > music with your software ? > > My live sessions in Paris are starting soon, and I plan to spend my > summer recording with my band. This is something I need to know. > AFAICT, and in the way I definitively read it, the COMMERCIAL use in the infamous linuxsampler license exception, refers ONLY to works in software and hardware (i.e. embedded software) products. Using linuxsampler for commercial *and* non-commercial music art (re)creation is not an issue. OTOH however, you MUST take special regard to the license terms of each and any of the GigaSampler files that you're loading and rendering with linuxsampler ;) Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From dlphillips at woh.rr.com Sun Jul 2 08:24:09 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun Jul 2 08:12:54 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A7AFCB.2020505@rncbc.org> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> Message-ID: <44A7BAE9.1080500@woh.rr.com> Something from the source : Christian Schoenebeck wrote on 9 Sept 2005: "Anyway, about the mentioned commercial exception in general: you can assume all current tarball releases of LS (up to and including 0.3.3) to be under pure GPL. It was already released as pure GPL and is already included in many distributions as pure GPL software, so don't worry about that. However we thought about changing the license in future to one which is more restrictive about commercial usage and we already placed those commercial exception notes just to be sure. The idea about such a possible new license was to allow "direct" commercial usage of LS only if the commercial actor supported this or another (important) open source project either directly by contributing code or indirectly by funding the respective project. So somebody who supported e.g. the GCC, ALSA or Jack Audio Connection Kit project might also be allowed to use LS commercially. "Commercial usage" would of course only mean products based on LS, it would of course not mean using LS e.g. for commercial music production or something. Such a license wouldn't mean anything negative for the user, but might "motivate" or force ;) more people to contribute to this or another open source project, so personally I would find such a license more beneficial (than GPL for example) for the open source community in general. Unfortunately I haven't found an existing open source license which would reflect those restrictions. Some even said this wouldn't be an open source license according to definitions of XY, but personally I think it would. So maybe we would have to write a new license, like a "Participation License" or something which might also be used by other projects in future of course. Best, dp From jens.andreasen at chello.se Sun Jul 2 10:20:25 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Jul 2 10:20:33 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060701120902.GA5951@linux-1.site> References: <20060629123800.GM10261@fitz.Belkin> <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> <20060630210440.GB25650@fitz.Belkin> <1151734936.9274.331.camel@c80-216-124-251.cm-upc.chello.se> <20060701120902.GA5951@linux-1.site> Message-ID: <1151850025.9274.345.camel@c80-216-124-251.cm-upc.chello.se> On Sat, 2006-07-01 at 14:09 +0200, Fons Adriaensen wrote: > On Sat, Jul 01, 2006 at 08:22:16AM +0200, Jens M Andreasen wrote: > > > Linear attack sounds OK. Given the exponential way we perceive volume, > > this *is* the desired function. > > That's the rationale for having exponential volume controls. [...] I am confused: s/exponential/logarithmic Now the curves in each section starts bending in the right direction /j From drobilla at connect.carleton.ca Sun Jul 2 10:45:57 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jul 2 10:46:09 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A7BAE9.1080500@woh.rr.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> Message-ID: <1151851557.19623.14.camel@localhost.localdomain> On Sun, 2006-07-02 at 08:24 -0400, Dave Phillips wrote: > Something from the source : > > Christian Schoenebeck wrote on 9 Sept 2005: > > "Anyway, about the mentioned commercial exception in general: you can assume > all current tarball releases of LS (up to and including 0.3.3) to be under > pure GPL. It was already released as pure GPL and is already included in many > distributions as pure GPL software, so don't worry about that. > > However we thought about changing the license in future to one which is more > restrictive about commercial usage and we already placed those commercial > exception notes just to be sure. > > The idea about such a possible new license was to allow "direct" commercial > usage of LS only if the commercial actor supported this or another > (important) open source project either directly by contributing code or > indirectly by funding the respective project. So somebody who supported e.g. > the GCC, ALSA or Jack Audio Connection Kit project might also be allowed to > use LS commercially. "Commercial usage" would of course only mean products > based on LS, it would of course not mean using LS e.g. for commercial music > production or something. Such a license wouldn't mean anything negative for > the user, but might "motivate" or force ;) more people to contribute to this > or another open source project, so personally I would find such a license > more beneficial (than GPL for example) for the open source community in > general. > > Unfortunately I haven't found an existing open source license which would > reflect those restrictions. Some even said this wouldn't be an open source > license according to definitions of XY, but personally I think it would. So > maybe we would have to write a new license, like a "Participation License" or > something which might also be used by other projects in future of course. It sounds like the LS devs don't want people _selling_ LS? That's not what "commercial use" means (I'm not sure what "direct" commercial usage is supposed to mean). Commercial USE it just that - using the software commercially, eg. to produce an album for sale. The exception needs to be reworded to refer specifically to sale. Point is this REALLY needs to be clarified. If using LS on commercial albums etc. isn't intended to be against the terms, the phrase "commercial use" should be removed completely. Though as far as being more beneficial, I really don't think LS being less widely distributed and not in any distributions because it's not OSS is going to benefit anyone, especially since it's a project with so much potential to replace a closed app with an open one (that runs in Linux). Try and fudge the definition of 'open source' all you want, but a project with such an exception will definitely never be included in any of the major distributions, and that just hurts "us". -DR- From a at gaydenko.com Sun Jul 2 10:57:57 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sun Jul 2 10:58:24 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <20060624153000.GA5950@linux-1.site> References: <200606241915.38534@goldspace.net> <20060624153000.GA5950@linux-1.site> Message-ID: <200607021857.57787@goldspace.net> Being under DSP studying, I have accidentally met Judith C. Brown paper about constant Q transform. An apparent thought is: constant Q transform is more direct way for SPL-observing rather FFT+smoothing. Is it so (I don't mean RT-apps)? ======= On Saturday 24 June 2006 19:30, Fons Adriaensen wrote: ======= On Sat, Jun 24, 2006 at 07:15:38PM +0400, Andrew Gaydenko wrote: > And the question is: what is common way to smooth the result? Some offtopic apps has > something like "1/24, ..., 1/3 octave smoothing". What does it mean? Lowpass (linear phase) filtering of the response. Or windowing the IR which is equivalent. If you window the IR, you get a constant resolution over the entire range of the FR. To get a variable rate such as 1/3 oct, you need frequency dependent windowing - the window gets shorter as frequency rises. It's not easy to do right (one of the reasons why aliki still isn't finished). IIRC DRC can produce such plots if you ask it nicely. -- FA Follie! Follie! Delirio vano e' questo! From A.Kuckartz at ping.de Sun Jul 2 12:30:46 2006 From: A.Kuckartz at ping.de (Andreas Kuckartz) Date: Sun Jul 2 12:31:36 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A7BAE9.1080500@woh.rr.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> Message-ID: <44A7F4B6.4000802@ping.de> Dave Phillips or Christian Schoenebeck wrote: > Unfortunately I haven't found an existing open source license which > would reflect those restrictions. Some even said this wouldn't be an > open source license according to definitions of XY, but personally I > think it would. I suggest that you read this: The Open Source Definition http://opensource.org/docs/definition.php Especially have a look at point 6 ("No Discrimination Against Fields of Endeavor"). > So maybe we would have to write a new license, like a > "Participation License" or something which might also > be used by other projects in future of course. Do so, but then do not tell anyone that this is an "Open Source"-license - it is not. Cheers, Andreas From nando at ccrma.Stanford.EDU Sun Jul 2 13:28:22 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sun Jul 2 13:28:29 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151783508.19306.20.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151782390.30130.7.camel@orchid.arb.net> <1151783508.19306.20.camel@localhost.localdomain> Message-ID: <1151861302.4434.8.camel@cmn3.stanford.edu> On Sat, 2006-07-01 at 15:51 -0400, Dave Robillard wrote: > On Sat, 2006-07-01 at 20:33 +0100, Bob Ham wrote: > > On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > > > Dave Robillard wrote: > > > > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > > > >>> LinuxSampler is not free software or open source software. > > > >>> > > > >> (sigh, must we, really?) > > > >> > > > >> It depends on who you choose to side with. > > > > > > It's just using a modified GPL License which isn't clearly labelled as > > > such. > > > > According to this URL > > > > http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/Sampler.cpp?rev=1.28&content-type=text/vnd.viewcvs-markup > > > > I have permission to use that particular file under the GPL, or (at my > > option) any later version. Looking through a few other files and I see > > I have the same permissions for those. Seems to be open source *and* > > free software *and* released under the GPL *and* free-as-in-beer. > > > > *shrug* > > Definitely, at the end of the day there is no way in hell their > "exception" would hold up in court, since they basically just mention it > in passing on the web page. Nope, it is (or at least was the last time I checked) mentioned in the, I think, README file in the tarballs, up to and including 0.3.3. -- Fernando From drobilla at connect.carleton.ca Sun Jul 2 13:48:50 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jul 2 13:48:57 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151861302.4434.8.camel@cmn3.stanford.edu> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151861302.4434.8.camel@cmn3.stanford.edu> Message-ID: <1151862530.22511.4.camel@localhost.localdomain> On Sun, 2006-07-02 at 10:28 -0700, Fernando Lopez-Lezcano wrote: > On Sat, 2006-07-01 at 15:51 -0400, Dave Robillard wrote: > > On Sat, 2006-07-01 at 20:33 +0100, Bob Ham wrote: > > > On Sat, 2006-07-01 at 23:53 +0700, Patrick Shirkey wrote: > > > > Dave Robillard wrote: > > > > > On Sat, 2006-07-01 at 17:43 +0200, Luis Garrido wrote: > > > > >>> LinuxSampler is not free software or open source software. > > > > >>> > > > > >> (sigh, must we, really?) > > > > >> > > > > >> It depends on who you choose to side with. > > > > > > > > It's just using a modified GPL License which isn't clearly labelled as > > > > such. > > > > > > According to this URL > > > > > > http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/Sampler.cpp?rev=1.28&content-type=text/vnd.viewcvs-markup > > > > > > I have permission to use that particular file under the GPL, or (at my > > > option) any later version. Looking through a few other files and I see > > > I have the same permissions for those. Seems to be open source *and* > > > free software *and* released under the GPL *and* free-as-in-beer. > > > > > > *shrug* > > > > Definitely, at the end of the day there is no way in hell their > > "exception" would hold up in court, since they basically just mention it > > in passing on the web page. > > Nope, it is (or at least was the last time I checked) mentioned in the, > I think, README file in the tarballs, up to and including 0.3.3. So I exxaggerated. :) But like Bob said, the above link points to a file that clearly says right in it that it's licensed under the GPL (v2 or later). There's a similar link for every other file in LS, provided by the LS people themselves. So, if you want a fully GPLed version of CVS LS, just go through and download every file with those links and you've got it. -DR- From dlphillips at woh.rr.com Sun Jul 2 14:37:57 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun Jul 2 14:26:38 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A7F4B6.4000802@ping.de> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> Message-ID: <44A81285.4030301@woh.rr.com> Andreas Kuckartz wrote: >Dave Phillips or Christian Schoenebeck wrote: > [snip] My apologies, the text is Christian's I forgot an end-quote. Just to be complete, here's the entire message, including Matt Flax's original query : Am Montag, 5. September 2005 04:40 schrieb Matt Flax: >> Hello, >> >> This person brought up an issue where the GPL is tainted by something >> written in one of the README files. >> >> IT is important for free software distributions such ad Debian that if >> you use a free software license you don't taint it ... I think they are >> concerned that you are trying to stop commercial use of Linux Sampler, >> even if the commercial product is GPL based. >> >> Is it possible to reword the below to : >> "This software is distributed under the GNU General Public License (see >> COPYING file), and may not be used in non GPL based or non GPL >> commercial applications without asking the authors for permission." > > [Christian's response starts here:] I'm not a license / GPL expert, but wouldn't that sentence simply be redundant? I mean the GPL forces all derived work to be under GPL as well, doesn't it? Anyway, about the mentioned commercial exception in general: you can assume all current tarball releases of LS (up to and including 0.3.3) to be under pure GPL. It was already released as pure GPL and is already included in many distributions as pure GPL software, so don't worry about that. However we thought about changing the license in future to one which is more restrictive about commercial usage and we already placed those commercial exception notes just to be sure. The idea about such a possible new license was to allow "direct" commercial usage of LS only if the commercial actor supported this or another (important) open source project either directly by contributing code or indirectly by funding the respective project. So somebody who supported e.g. the GCC, ALSA or Jack Audio Connection Kit project might also be allowed to use LS commercially. "Commercial usage" would of course only mean products based on LS, it would of course not mean using LS e.g. for commercial music production or something. Such a license wouldn't mean anything negative for the user, but might "motivate" or force ;) more people to contribute to this or another open source project, so personally I would find such a license more beneficial (than GPL for example) for the open source community in general. Unfortunately I haven't found an existing open source license which would reflect those restrictions. Some even said this wouldn't be an open source license according to definitions of XY, but personally I think it would. So maybe we would have to write a new license, like a "Participation License" or something which might also be used by other projects in future of course. Anyway, no decision is made as of today. But would be interesting to know what you people think of it! CU Christian ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel From pshirkey at boosthardware.com Sun Jul 2 15:26:24 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sun Jul 2 15:27:51 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A81285.4030301@woh.rr.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> Message-ID: <44A81DE0.7010705@boosthardware.com> Christian wrote: > > > Unfortunately I haven't found an existing open source license which > would reflect those restrictions. Some even said this wouldn't be an > open source license according to definitions of XY, but personally I > think it would. So maybe we would have to write a new license, like a > "Participation License" or something which might also be used by other > projects in future of course. > > Anyway, no decision is made as of today. But would be interesting to > know what you people think of it! > If they really want to get people to give money then they should just make it so that you have to pay or contribute code/time for a while to get access to the newest downloads from their site. Keep the stable version far enough behind the development version that people will pay to get the newest code base. Codeweavers use this kind of approach (although you can't get a stable version for free anywhere AFAIK) and I have also seen an even more aggressive approach used by the KVCD developers. It's very difficult to find easy to grok information about how to make a KVCD but you can get it easily and quickly for $4 from their "closed" forum. $4 or $5 can be handled by a lot more people than $300 - $2000 which some other similar software is selling for. BTW KVCD has a few thousand forum members. It won't stop all the people who want to get a free copy but it should keep most of the freeloaders at bay. It will also serve to make the developers "appear" more professionally oriented to a non initiated user. If they are not prepared to do something like that then they should just forget about trying to get a big company to give them any money because they will get eaten alive by lawyers as the FSF most probably won't be able to help them if they change the license. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From loki.davison at gmail.com Sun Jul 2 21:23:25 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Jul 2 21:23:32 2006 Subject: [linux-audio-dev] Re: fst, VST 2.0, kontakt In-Reply-To: <1151764969.19306.0.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: On 7/2/06, Dave Robillard wrote: > On Fri, 2006-06-30 at 15:54 +0100, Robert Ham wrote: > > On Fri, Jun 30, 2006 at 10:25:04AM -0400, Forest Bond wrote: > > > > > As far as I can tell there are two resolutions: > > > > > > 1) someone works on fst to make it save kontakt's state > > > 2) someone writes a free kontakt replacement > > > > 3) someone makes Linux Sampler do what Kontakt does > > LinuxSampler is not free software or open source software. > > -DR- Also it's not really a sampler as such. It's more of a rom player. Something like specimen or probably much chionic is more suited. Chionic is looking for new guys to help out if i remember right, help them out, and you get what you want! ;) Loki From d.sbragion at infotecna.it Mon Jul 3 03:07:55 2006 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Mon Jul 3 03:08:11 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <200607021857.57787@goldspace.net> References: <200606241915.38534@goldspace.net> <20060624153000.GA5950@linux-1.site> <200607021857.57787@goldspace.net> Message-ID: <1182.192.168.1.13.1151910475.squirrel@www.infotecna.lcl> Hello Andrew, On Sun, July 2, 2006 16:57, Andrew Gaydenko wrote: ... > way for SPL-observing rather FFT+smoothing. Is it so (I don't mean RT-apps)? usually, yes. AFAIK there's no transform that really mimimcs our perception, i.e. which provides a visual representation similar enough to the auditory perception. Take also a look at the Stockwell transform, which is a somewhat balanced compromise between the properties of the FFT and the properties of the wavelet transform. ... > IIRC DRC can produce such plots if you ask it nicely. BTW frequency dependent windowing and standard fractional octave smoothing aren't completely equivalent. There's instead a proven equivalence between frequency dependent windowing and *complex* smoothing. See the Mourjopoulos papers for further details. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From rah at bash.sh Mon Jul 3 05:51:09 2006 From: rah at bash.sh (Robert Ham) Date: Mon Jul 3 05:51:23 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A81285.4030301@woh.rr.com> References: <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> Message-ID: <20060703095109.GA7757@teasel.arb.net> On Sun, Jul 02, 2006 at 02:37:57PM -0400, Dave Phillips wrote: > Andreas Kuckartz wrote: > My apologies, the text is Christian's I forgot an end-quote. Just to be > complete, here's the entire message, including Matt Flax's original query : > > Am Montag, 5. September 2005 04:40 schrieb Matt Flax: > >>This person brought up an issue where the GPL is tainted by something > >>written in one of the README files. > [Christian's response starts here:] > The idea about such a possible new license was to allow "direct" commercial > usage of LS only if the commercial actor supported this or another > (important) open source project either directly by contributing code or > indirectly by funding the respective project. So somebody who supported > e.g. the GCC, ALSA or Jack Audio Connection Kit project might also be > allowed to use LS commercially. "Commercial usage" would of course only > mean products based on LS, it would of course not mean using LS e.g. for > commercial music production or something. Why would you allow one particular type of commercial usage which does not provide support for free software projects? What is the difference between that particular type of commercial usage, and any other type? Bob From fons.adriaensen at alcatelaleniaspace.com Mon Jul 3 06:33:11 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jul 3 06:33:26 2006 Subject: [linux-audio-dev] [ANN] Aqualung 0.9beta5 released In-Reply-To: <44A4F47D.3010201@gmail.com> References: <44A4F47D.3010201@gmail.com> Message-ID: <20060703103311.GA6007@bth05w.ABSp.alcatel.be> On Fri, Jun 30, 2006 at 11:53:01AM +0200, Tom Szilagyi wrote: > Aqualung: Music Player for GNU/Linux > Release 0.9beta5 This looked like the player I've been wanting for some time (all formats, jackified), so I installed in on a fairly standard SuSE 10.0 this WE. It compiled and installed without problem, but so far it chokes on all *.ogg I've tried. Either the CPU load goes up to 100% and no sound (OK again after stop) or playback seems to start but then stop immmediately. I've only had limited time exploring this, but will try to get deeper into it later. Any hints ? I'm using Aqualung as a JACK client, started (as all JACK apps here) via sudo. -- FA Follie! Follie! Delirio vano e' questo! From mista.tapas at gmx.net Mon Jul 3 06:52:42 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Mon Jul 3 06:52:52 2006 Subject: [linux-audio-dev] [ANN] Aqualung 0.9beta5 released In-Reply-To: <20060703103311.GA6007@bth05w.ABSp.alcatel.be> References: <44A4F47D.3010201@gmail.com> <20060703103311.GA6007@bth05w.ABSp.alcatel.be> Message-ID: <20060703125242.1383cb33@mango.fruits> On Mon, 3 Jul 2006 12:33:11 +0200 Alfons Adriaensen wrote: > On Fri, Jun 30, 2006 at 11:53:01AM +0200, Tom Szilagyi wrote: > > > Aqualung: Music Player for GNU/Linux > > Release 0.9beta5 > > This looked like the player I've been wanting for some time > (all formats, jackified), so I installed in on a fairly > standard SuSE 10.0 this WE. It compiled and installed > without problem, but so far it chokes on all *.ogg > I've tried. Either the CPU load goes up to 100% and no > sound (OK again after stop) or playback seems to start > but then stop immmediately. > > I've only had limited time exploring this, but will try > to get deeper into it later. Any hints ? I'm using Aqualung > as a JACK client, started (as all JACK apps here) via sudo. Just a guess. Did you choose a different samplerate converter than the fastest? That was what it is choking on here sometimes. The fastest works fine here [though of course with reduced sound quality].. Flo -- Palimm Palimm! http://tapas.affenbande.org From fons.adriaensen at alcatelaleniaspace.com Mon Jul 3 07:34:50 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jul 3 07:35:06 2006 Subject: [linux-audio-dev] [ANN] Aqualung 0.9beta5 released In-Reply-To: <20060703125242.1383cb33@mango.fruits> References: <44A4F47D.3010201@gmail.com> <20060703103311.GA6007@bth05w.ABSp.alcatel.be> <20060703125242.1383cb33@mango.fruits> Message-ID: <20060703113450.GB6007@bth05w.ABSp.alcatel.be> On Mon, Jul 03, 2006 at 12:52:42PM +0200, Florian Paul Schmidt wrote: > Just a guess. Did you choose a different samplerate converter than the > fastest? That was what it is choking on here sometimes. The fastest > works fine here [though of course with reduced sound quality].. I used the 'medium' one IIRC. But then I also played some 44.1k WAVs that were nicely resampled to 48k... -- FA Follie! Follie! Delirio vano e' questo! From ico.bukvic at gmail.com Mon Jul 3 08:13:41 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Mon Jul 3 08:14:05 2006 Subject: [linux-audio-dev] Call for all LA projects Message-ID: <000301c69e9a$210cd880$6602a8c0@64BitBadass> Linuxaudio.org is getting ready to announce new memberships in the coming weeks. For this reason, I would like to invite all Linux Audio projects and its members, as well as other allied projects, institutions, companies, and hardware vendors to consider joining our organization. HOW TO JOIN Simply send an e-mail to ico at linuxaudio dot org stating your interest to join. There are no dues or hidden costs and the membership can be terminated at any time via member's written request. BENEFITS As the consortium grows, we strive to provide a focal, converging point through which we will represent our community, offer new opportunities for collaboration and interaction, represent and preserve interests of the community, as well as serve as a point of contact for commercial industry and hardware vendors. For more info please visit linuxaudio.org or do not hesitate to contact me directly. Best wishes, Ivica Ico Bukvic, D.M.A. Composition Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-7047 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic/ From forest at alittletooquiet.net Mon Jul 3 08:27:50 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Mon Jul 3 08:28:02 2006 Subject: [linux-audio-dev] Re: fst, VST 2.0, kontakt In-Reply-To: References: <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: <20060703122750.GA28701@localdomain> On Mon, Jul 03, 2006 at 11:23:25AM +1000, Loki Davison wrote: > On 7/2/06, Dave Robillard wrote: > >On Fri, 2006-06-30 at 15:54 +0100, Robert Ham wrote: > >> On Fri, Jun 30, 2006 at 10:25:04AM -0400, Forest Bond wrote: > >> > >> > As far as I can tell there are two resolutions: > >> > > >> > 1) someone works on fst to make it save kontakt's state > >> > 2) someone writes a free kontakt replacement > >> > >> 3) someone makes Linux Sampler do what Kontakt does > > > >LinuxSampler is not free software or open source software. > > > >-DR- > > > Also it's not really a sampler as such. It's more of a rom player. > Something like specimen or probably much chionic is more suited. > Chionic is looking for new guys to help out if i remember right, help > them out, and you get what you want! ;) All I can find on chionic are some old lad/lau/laa posts that indicate it is no longer maintained, but had some neat features. The site seems to be gone. Where can I get source? -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060703/6208dd23/attachment.bin From paul at linuxaudiosystems.com Mon Jul 3 08:33:10 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jul 3 08:32:38 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A81DE0.7010705@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> Message-ID: <1151929990.10662.87.camel@localhost.localdomain> On Mon, 2006-07-03 at 02:26 +0700, Patrick Shirkey wrote: > If they really want to get people to give money then they should just > make it so that you have to pay or contribute code/time for a while to > get access to the newest downloads from their site. Keep the stable > version far enough behind the development version that people will pay > to get the newest code base. its really rather amusing to see people speculating on what the developers of LS could or could not do, when the actual relevant "encounter" with "commercial interests" has *already* happened. it did not go well. it can be tempting to imagine that we understand the motivations of commercial organizations and can therefore offer them appropriate carrots. don't be so confident of this. both the LS developers and myself are under the terms of an NDA, so it is not possible to discuss with any relevant detail precisely what happened. but it was nasty, it was unpleasant and as i've said before, it would be better for people to not make so many assumptions about their ability to guess at what might or might happen when a commercial company shows interest in a tool like LS. --p From Jan.Weil at web.de Mon Jul 3 08:35:47 2006 From: Jan.Weil at web.de (Jan Weil) Date: Mon Jul 3 08:35:52 2006 Subject: [linux-audio-dev] Re: fst, VST 2.0, kontakt In-Reply-To: <20060703122750.GA28701@localdomain> References: <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <20060703122750.GA28701@localdomain> Message-ID: <44A90F23.4010900@web.de> Forest Bond schrieb: >> Also it's not really a sampler as such. It's more of a rom player. >> Something like specimen or probably much chionic is more suited. >> Chionic is looking for new guys to help out if i remember right, help >> them out, and you get what you want! ;) > > All I can find on chionic are some old lad/lau/laa posts that indicate it is no > longer maintained, but had some neat features. The site seems to be gone. > > Where can I get source? From fons.adriaensen at skynet.be Mon Jul 3 13:15:00 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Mon Jul 3 13:14:39 2006 Subject: [linux-audio-dev] [OT] No-one was ever fired for having hired FA Message-ID: <20060703171500.GA5947@linux-1.site> Hello all, I finally took the big step and handed in my resignation at my employer, Alcatel Alenia Space. After 3 years of CAD, 3 years of real-time kernels, and 11 years in space telecoms, I want to return to my first love which is audio, acoustics, and music. My activities in LAD have certainly contributed to this desire. It will be at least end of september before I really say goodbye at AAS, and I have at this moment no idea at all which way I will go. Which means I'm open to suggestions. I will consider 'a real job' if it's related to acoustics, audio engineering, ambisonics, electro-acoustic music etc. For this type of thing I'm also prepared to move to France, Germany, and any of the European countries bordering the Mare Nostrum. I speak Portuguese (needs refreshing), I am currently learning Greek, and if necessary I'll add Spanish or Italian. I'm not really looking for a job as a programmer. The alternative is of course free-lance consultancy work. And if all else fails, I will be raising sheep on Crete. Anyone interested or having interesting pointers please contact me off-list. (and no, I'm not quitting LAD :) -- FA Follie! Follie! Delirio vano e' questo! From pshirkey at boosthardware.com Mon Jul 3 16:51:30 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon Jul 3 16:52:48 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151929990.10662.87.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> Message-ID: <44A98352.7020407@boosthardware.com> Paul Davis wrote: > On Mon, 2006-07-03 at 02:26 +0700, Patrick Shirkey wrote: >> If they really want to get people to give money then they should just >> make it so that you have to pay or contribute code/time for a while to >> get access to the newest downloads from their site. Keep the stable >> version far enough behind the development version that people will pay >> to get the newest code base. > > its really rather amusing to see people speculating on what the > developers of LS could or could not do, when the actual relevant > "encounter" with "commercial interests" has *already* happened. it did > not go well. it can be tempting to imagine that we understand the > motivations of commercial organizations and can therefore offer them > appropriate carrots. don't be so confident of this. both the LS > developers and myself are under the terms of an NDA, so it is not > possible to discuss with any relevant detail precisely what happened. > but it was nasty, it was unpleasant and as i've said before, it would be > better for people to not make so many assumptions about their ability to > guess at what might or might happen when a commercial company shows > interest in a tool like LS. > Sorry Paul, You have mentioned this in the past. I didn't mean to drag up those memories. It completely slipped my mind that something funky had gone on with LS. On saying that though it really is a bummer that the NDA prevents certain people from discussing the valuable knowledge learned from that encounter. It's still entirely legal for others to speculate though... If we ask questions and you don't answer then maybe that's legal too... It seems to me that some company tried to use the work done by the LS team without giving anything/much in return. The strange appearance of the modification to the GPL in the LS README seems like a direct response to the situation that occured when things didn't work out for the LS team with regards to this mystery company. History provides plenty of evidence of companies/business people taking, using and abusing and not giving in return. It seems strange that the LS team would choose to work under the GPL and then be surprised if someone tried to take advantage of them. However it is perfectly reasonable for that to have severe emotional impact when so much hard work is effectively "stolen" by greedy "business" people. It reminds me of the 6 years I have spent working in Asia. Everything I have done for free is ripped off by others who can't come up with their own ideas. Now I *only* do things for fun or money up front. Life is too damn short to let the bastards of this world abuse my time/energy/motivation. Hence why I enjoy working with Linux Audio. Where the real bastards are few and far between. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From lars.luthman at gmail.com Mon Jul 3 17:31:09 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jul 3 17:31:22 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A98352.7020407@boosthardware.com> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> Message-ID: <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> On Tue, 2006-07-04 at 03:51 +0700, Patrick Shirkey wrote: > It's still entirely legal for others to speculate though... If we ask > questions and you don't answer then maybe that's legal too... > > It seems to me that some company tried to use the work done by the LS > team without giving anything/much in return. The strange appearance of > the modification to the GPL in the LS README seems like a direct > response to the situation that occured when things didn't work out for > the LS team with regards to this mystery company. That does not explain why the authors signed an NDA. I think it is more likely that the "mystery company" had a (possibly vague and unlikely to hold up in court, but what free software author could afford to take it to court anyway) patent on some technique used by LinuxSampler, and threatened them with a lawsuit if the authors didn't make sure that LinuxSampler couldn't be used by some commercial competitor to the mystery company, and promised not to mention anything about the whole thing. > [snip] > > Hence why I enjoy working with Linux Audio. Where the real bastards are > few and far between. But we are still here! -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060703/49007697/attachment.bin From paul at linuxaudiosystems.com Mon Jul 3 17:55:11 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jul 3 17:55:03 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1151963711.10662.112.camel@localhost.localdomain> On Mon, 2006-07-03 at 23:31 +0200, Lars Luthman wrote: > On Tue, 2006-07-04 at 03:51 +0700, Patrick Shirkey wrote: > > It's still entirely legal for others to speculate though... If we ask > > questions and you don't answer then maybe that's legal too... > > > > It seems to me that some company tried to use the work done by the LS > > team without giving anything/much in return. The strange appearance of > > the modification to the GPL in the LS README seems like a direct > > response to the situation that occured when things didn't work out for > > the LS team with regards to this mystery company. > > That does not explain why the authors signed an NDA. I think it is more > likely that the "mystery company" had a (possibly vague and unlikely to > hold up in court, but what free software author could afford to take it > to court anyway) patent on some technique used by LinuxSampler, and > threatened them with a lawsuit if the authors didn't make sure that > LinuxSampler couldn't be used by some commercial competitor to the > mystery company, and promised not to mention anything about the whole both guesses are wrong. i think it will be precise enough to say that a company expressed what appeared to be a serious interest in leveraging the existence of LS for its own plans. relationships changed between the various parties, and the LS developers were left in a situation where work they had already done might be used in ways they did not consent to. Meanwhile, the company felt that it was the LS developers who had failed to follow through on the agreement. i don't think its feasible to be more precise than this. the core point of the story is that you cannot stop other organizations from making use of your GPL-licensed work even if you have entered into some different kind of arrangement with them. for some people, this represents a serious issue. --p From drobilla at connect.carleton.ca Mon Jul 3 17:55:42 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jul 3 17:56:18 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151929990.10662.87.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> Message-ID: <1151963742.12737.25.camel@localhost.localdomain> On Mon, 2006-07-03 at 08:33 -0400, Paul Davis wrote: > On Mon, 2006-07-03 at 02:26 +0700, Patrick Shirkey wrote: > > If they really want to get people to give money then they should just > > make it so that you have to pay or contribute code/time for a while to > > get access to the newest downloads from their site. Keep the stable > > version far enough behind the development version that people will pay > > to get the newest code base. > > its really rather amusing to see people speculating on what the > developers of LS could or could not do, when the actual relevant > "encounter" with "commercial interests" has *already* happened. it did > not go well. it can be tempting to imagine that we understand the > motivations of commercial organizations and can therefore offer them > appropriate carrots. don't be so confident of this. both the LS > developers and myself are under the terms of an NDA, so it is not > possible to discuss with any relevant detail precisely what happened. > but it was nasty, it was unpleasant and as i've said before, it would be > better for people to not make so many assumptions about their ability to > guess at what might or might happen when a commercial company shows > interest in a tool like LS. Everyone can make assumptions about what they can or can't do until the cows come home, but it's irrelevant. The point it the license needs clarification. The disclaimer in the README is along the lines of what they intend to say (judging by the previously pasted quotes). The disclaimer on the webpage clearly makes it illegal to use LS on a CD you intend to sell, or in public concerts you sell tickets to (a goal that is specifically mentioned on the About page I might add), so if that isn't the intention it should be fixed. There is no disclaimer on the source files at all, so those are pure GPL with no commercial restrictions whatsoever. What IS the license to LinuxSampler? Who knows. They certainly havn't told us. -DR- From forums at machinehasnoagenda.com Mon Jul 3 19:01:45 2006 From: forums at machinehasnoagenda.com (Shayne O'Connor) Date: Mon Jul 3 19:01:58 2006 Subject: [linux-audio-dev] [OT] No-one was ever fired for having hired FA In-Reply-To: <20060703171500.GA5947@linux-1.site> References: <20060703171500.GA5947@linux-1.site> Message-ID: <1151967705.9273.3.camel@localhost.localdomain> On Mon, 2006-07-03 at 19:15 +0200, Fons Adriaensen wrote: > I'm not really looking for a job as a programmer. > The alternative is of course free-lance consultancy work. > And if all else fails, I will be raising sheep on Crete. i've never heard a better "if all else fails" than that :) kinda makes failing desirable! good luck! shayne From pshirkey at boosthardware.com Mon Jul 3 19:27:54 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon Jul 3 19:29:03 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151963742.12737.25.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <1151963742.12737.25.camel@localhost.localdomain> Message-ID: <44A9A7FA.7040101@boosthardware.com> Dave Robillard wrote: > > What IS the license to LinuxSampler? Who knows. They certainly havn't > told us. > Well, They have given us at least three different possibilities... -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From ryan at ryanheise.com Mon Jul 3 20:22:35 2006 From: ryan at ryanheise.com (Ryan Heise) Date: Mon Jul 3 20:22:47 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151963711.10662.112.camel@localhost.localdomain>; from paul@linuxaudiosystems.com on Mon, Jul 03, 2006 at 05:55:11PM -0400 References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> Message-ID: <20060704102235.C6994@linus.it.uts.EDU.AU> On Mon, Jul 03, 2006 at 05:55:11PM -0400, Paul Davis wrote: > both guesses are wrong. i think it will be precise enough to say that a > company expressed what appeared to be a serious interest in leveraging > the existence of LS for its own plans. relationships changed between the > various parties, and the LS developers were left in a situation where > work they had already done might be used in ways they did not consent > to. Meanwhile, the company felt that it was the LS developers who had > failed to follow through on the agreement. i don't think its feasible to > be more precise than this. > > the core point of the story is that you cannot stop other organizations > from making use of your GPL-licensed work even if you have entered into > some different kind of arrangement with them. for some people, this > represents a serious issue. Licensing software under the GPL is giving others consent to use that software commercially in certain ways. If there was an additional agreement with this specific company that they would not use it in some of those ways, it still wouldn't stop other companies who haven't signed that additional agreement to use the software in whatever way was granted to them under the GPL. What confuses me is why the authors of the software chose to release the code under the GPL and also didn't (as it seems) want to consent to others using the software in some of the ways granted by the GPL. Do I have the wrong picture? (maybe I do, I am just going on the little information provided above.) -- Ryan Heise http://www.ryanheise.com/ From paul at linuxaudiosystems.com Mon Jul 3 21:09:04 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jul 3 21:09:01 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060704102235.C6994@linus.it.uts.EDU.AU> References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> <20060704102235.C6994@linus.it.uts.EDU.AU> Message-ID: <1151975344.10662.124.camel@localhost.localdomain> On Tue, 2006-07-04 at 10:22 +1000, Ryan Heise wrote: > On Mon, Jul 03, 2006 at 05:55:11PM -0400, Paul Davis wrote: > > both guesses are wrong. i think it will be precise enough to say that a > > company expressed what appeared to be a serious interest in leveraging > > the existence of LS for its own plans. relationships changed between the > > various parties, and the LS developers were left in a situation where > > work they had already done might be used in ways they did not consent > > to. Meanwhile, the company felt that it was the LS developers who had > > failed to follow through on the agreement. i don't think its feasible to > > be more precise than this. > > > > the core point of the story is that you cannot stop other organizations > > from making use of your GPL-licensed work even if you have entered into > > some different kind of arrangement with them. for some people, this > > represents a serious issue. > > Licensing software under the GPL is giving others consent to use that > software commercially in certain ways. If there was an additional > agreement with this specific company that they would not use it in some > of those ways, it still wouldn't stop other companies who haven't signed > that additional agreement to use the software in whatever way was > granted to them under the GPL. What confuses me is why the authors of > the software chose to release the code under the GPL and also didn't (as > it seems) want to consent to others using the software in some of the > ways granted by the GPL. Do I have the wrong picture? (maybe I do, I am > just going on the little information provided above.) there is a big difference in how a developer might see this depending on the relationship with the other party. lets take a concrete case that i *can* talk about freely. we are quite open about the fact that there are commercial organizations that have both financially supported Ardour's development and have also been evangelizing for it quite energetically in some key high end markets. that has created positive relationships to date. now suppose (and i want to stress that i am not for one moment suggesting that i believe that this will happen) that one such relationship turned ugly. lets say, really ugly. really ugly as in "if you ever even talk about how ugly this got, we'll see you in court, if not before.". or uglier. you get the idea. how do you think that i and the many other people who have worked on ardour would feel about allowing a company that ended up putting us in this situation to continue to ardour under the GPL? we would not be able to stop it, and i would hope that i would have the honor and class not to even try, but it would clearly leave a very sour taste in my mouth (and others' mouths too, i suspect). something broadly analogous to this happened to the LS guys. unless you can say in all sincerity that you'd be able to just wave it past you, smile sweetly and mutter "oh, that's just the GPL at work", i think you have to be careful when judging other people's actions. and for this history buffs, i seem to recall that it was precisely this kind of situation that gave rise to the Aladdin Public License, from the person who wrote GhostScript. --p From A.Kuckartz at ping.de Tue Jul 4 01:48:43 2006 From: A.Kuckartz at ping.de (Andreas Kuckartz) Date: Tue Jul 4 01:49:01 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151975344.10662.124.camel@localhost.localdomain> References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> <20060704102235.C6994@linus.it.uts.EDU.AU> <1151975344.10662.124.camel@localhost.localdomain> Message-ID: <44AA013B.9080508@ping.de> I have a simple question: Which companies are (or have been) distributing LinuxSampler as part of a package also including hardware and/or proprietary software? Cheers, Andreas --- Paul Davis wrote: > On Tue, 2006-07-04 at 10:22 +1000, Ryan Heise wrote: > >> On Mon, Jul 03, 2006 at 05:55:11PM -0400, Paul Davis wrote: >> >>> both guesses are wrong. i think it will be precise enough to say that a >>> company expressed what appeared to be a serious interest in leveraging >>> the existence of LS for its own plans. relationships changed between the >>> various parties, and the LS developers were left in a situation where >>> work they had already done might be used in ways they did not consent >>> to. Meanwhile, the company felt that it was the LS developers who had >>> failed to follow through on the agreement. i don't think its feasible to >>> be more precise than this. >>> >>> the core point of the story is that you cannot stop other organizations >>> from making use of your GPL-licensed work even if you have entered into >>> some different kind of arrangement with them. for some people, this >>> represents a serious issue. >>> >> Licensing software under the GPL is giving others consent to use that >> software commercially in certain ways. If there was an additional >> agreement with this specific company that they would not use it in some >> of those ways, it still wouldn't stop other companies who haven't signed >> that additional agreement to use the software in whatever way was >> granted to them under the GPL. What confuses me is why the authors of >> the software chose to release the code under the GPL and also didn't (as >> it seems) want to consent to others using the software in some of the >> ways granted by the GPL. Do I have the wrong picture? (maybe I do, I am >> just going on the little information provided above.) >> > > there is a big difference in how a developer might see this depending on > the relationship with the other party. lets take a concrete case that i > *can* talk about freely. we are quite open about the fact that there are > commercial organizations that have both financially supported Ardour's > development and have also been evangelizing for it quite energetically > in some key high end markets. that has created positive relationships to > date. > > now suppose (and i want to stress that i am not for one moment > suggesting that i believe that this will happen) that one such > relationship turned ugly. lets say, really ugly. really ugly as in "if > you ever even talk about how ugly this got, we'll see you in court, if > not before.". or uglier. you get the idea. > > how do you think that i and the many other people who have worked on > ardour would feel about allowing a company that ended up putting us in > this situation to continue to ardour under the GPL? > > we would not be able to stop it, and i would hope that i would have the > honor and class not to even try, but it would clearly leave a very sour > taste in my mouth (and others' mouths too, i suspect). > > something broadly analogous to this happened to the LS guys. unless you > can say in all sincerity that you'd be able to just wave it past you, > smile sweetly and mutter "oh, that's just the GPL at work", i think you > have to be careful when judging other people's actions. > > and for this history buffs, i seem to recall that it was precisely this > kind of situation that gave rise to the Aladdin Public License, from the > person who wrote GhostScript. > > --p > > > > > From loki.davison at gmail.com Tue Jul 4 02:09:21 2006 From: loki.davison at gmail.com (Loki Davison) Date: Tue Jul 4 02:09:28 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44AA013B.9080508@ping.de> References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> <20060704102235.C6994@linus.it.uts.EDU.AU> <1151975344.10662.124.camel@localhost.localdomain> <44AA013B.9080508@ping.de> Message-ID: On 4 Jul 2006 07:48:43 +0200, Andreas Kuckartz wrote: > I have a simple question: > > Which companies are (or have been) distributing LinuxSampler as part of > a package also including hardware and/or proprietary software? > > Cheers, > Andreas > --- > Liontracs do right? From rncbc at rncbc.org Tue Jul 4 04:32:00 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Tue Jul 4 04:33:02 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151963742.12737.25.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <1151963742.12737.25.camel@localhost.localdomain> Message-ID: <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> On Mon, July 3, 2006 22:55, Dave Robillard wrote: > On Mon, 2006-07-03 at 08:33 -0400, Paul Davis wrote: > >> On Mon, 2006-07-03 at 02:26 +0700, Patrick Shirkey wrote: >> >>> If they really want to get people to give money then they should just >>> make it so that you have to pay or contribute code/time for a while >>> to get access to the newest downloads from their site. Keep the stable >>> version far enough behind the development version that people will >>> pay to get the newest code base. >> >> its really rather amusing to see people speculating on what the >> developers of LS could or could not do, when the actual relevant >> "encounter" with "commercial interests" has *already* happened. it did >> not go well. it can be tempting to imagine that we understand the >> motivations of commercial organizations and can therefore offer them >> appropriate carrots. don't be so confident of this. both the LS >> developers and myself are under the terms of an NDA, so it is not >> possible to discuss with any relevant detail precisely what happened. >> but it was nasty, it was unpleasant and as i've said before, it would >> be better for people to not make so many assumptions about their ability >> to guess at what might or might happen when a commercial company shows >> interest in a tool like LS. > > Everyone can make assumptions about what they can or can't do until the > cows come home, but it's irrelevant. The point it the license needs > clarification. > > The disclaimer in the README is along the lines of what they intend to > say (judging by the previously pasted quotes). The disclaimer on the > webpage clearly makes it illegal to use LS on a CD you intend to sell, or > in public concerts you sell tickets to (a goal that is specifically > mentioned on the About page I might add), so if that isn't the intention > it should be fixed. There is no disclaimer on the source files at all, so > those are pure GPL with no commercial restrictions whatsoever. > > What IS the license to LinuxSampler? Who knows. They certainly havn't > told us. > We already know that the LS license is currently flawed. As Christian wrote explicitly, even thought the README file still has the infamous exception wording, *ALL* public releases of LinuxSampler until and including 0.3.3 *ARE* plain GPL. That last public release was more than one year ago. Since then, LinuxSampler code in CVS has changed in many pervasive ways, and AFAICT for the better, performance and feature-wise. I strongly believe (although I'm also speculating here;) the next public release of LinuxSampler, whenever it will be ready, will come with a proper open-source license. And I pretty guess it will be pure GPL but I just cannot garantee that yet ;) Now, regarding the so-called unclear license of LinuxSampler, why don't you people just read the FAQ (http://www.linuxsampler.org/faq.html), having special attention to the very first two questions? and rest relaxed at least for a while... :) Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From paul at linuxaudiosystems.com Tue Jul 4 08:44:45 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jul 4 08:44:12 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44AA013B.9080508@ping.de> References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> <20060704102235.C6994@linus.it.uts.EDU.AU> <1151975344.10662.124.camel@localhost.localdomain> <44AA013B.9080508@ping.de> Message-ID: <1152017085.10662.136.camel@localhost.localdomain> On Tue, 2006-07-04 at 07:48 +0200, Andreas Kuckartz wrote: > I have a simple question: > > Which companies are (or have been) distributing LinuxSampler as part of > a package also including hardware and/or proprietary software? as noted liontracs do, and that means that is incumbent upon me to stress that liontracs are *not* the commercial entity that i have alluded to in my descriptions of what may or may not have taken place with LS. From mobarre at gmail.com Tue Jul 4 12:41:34 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jul 4 12:41:41 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> References: <20060630003707.GE20075@storm.local.network> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <1151963742.12737.25.camel@localhost.localdomain> <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> Message-ID: <3c808a150607040941s120f826bge6225184b47075b1@mail.gmail.com> > Now, regarding the so-called unclear license of LinuxSampler, why don't > you people just read the FAQ (http://www.linuxsampler.org/faq.html), > having special attention to the very first two questions? and rest relaxed > at least for a while... :) Don't worry Rui, I will keep on using LS with my band, and it will surely be a part of the distro I am curently working on (a Music distro based on LFS... I'll post something here when the 0.1 release is ready ;-) hehe) Seeing what Paul explained I do have a better view of how and why things turned this way, and I am sure LS will be back pure GPL someday. Keep up the good work. ________________ Marc-Olivier Barre, Kinoko en Orbite. From capocasa at gmx.net Tue Jul 4 12:42:39 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Jul 4 12:43:44 2006 Subject: [linux-audio-dev] Re: [OT] No-one was ever fired for having hired FA In-Reply-To: <20060703171500.GA5947@linux-1.site> References: <20060703171500.GA5947@linux-1.site> Message-ID: You could do what I-m doing: Become a famous musician, start your own production company, give away all your music Creative Commons style, manage to get income indirectly, use free software tools exclusively, and figure out all the 'hows' on the way! From mobarre at gmail.com Tue Jul 4 12:49:11 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jul 4 12:49:18 2006 Subject: [linux-audio-dev] Re: [OT] No-one was ever fired for having hired FA In-Reply-To: References: <20060703171500.GA5947@linux-1.site> Message-ID: <3c808a150607040949jb5eb6fbs1369f3c79eb744df@mail.gmail.com> On 7/4/06, Carlo Capocasa wrote: > You could do what I-m doing: Become a famous musician, start your own > production company, give away all your music Creative Commons style, > manage to get income indirectly, use free software tools exclusively, > and figure out all the 'hows' on the way! If only I had the guts.... I'd send universal music and Sony to hell ;-) at least I have the creative commons and the free software tools part right. All I need is to become famous and start my company. Let's get to work ! ________________ Marc-Olivier Barre. Kinoko en Orbite. From capocasa at gmx.net Tue Jul 4 12:53:19 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Jul 4 12:53:37 2006 Subject: [linux-audio-dev] Re: [OT] No-one was ever fired for having hired FA In-Reply-To: <3c808a150607040949jb5eb6fbs1369f3c79eb744df@mail.gmail.com> References: <20060703171500.GA5947@linux-1.site> <3c808a150607040949jb5eb6fbs1369f3c79eb744df@mail.gmail.com> Message-ID: It helps to repeat to yourself many times every day: "I'm either going to do this or die trying." From drobilla at connect.carleton.ca Tue Jul 4 13:49:41 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 4 13:49:49 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <1151963742.12737.25.camel@localhost.localdomain> <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> Message-ID: <1152035381.25105.16.camel@localhost.localdomain> On Tue, 2006-07-04 at 09:32 +0100, Rui Nuno Capela wrote: > On Mon, July 3, 2006 22:55, Dave Robillard wrote: > > On Mon, 2006-07-03 at 08:33 -0400, Paul Davis wrote: > > > >> On Mon, 2006-07-03 at 02:26 +0700, Patrick Shirkey wrote: > >> > >>> If they really want to get people to give money then they should just > >>> make it so that you have to pay or contribute code/time for a while > >>> to get access to the newest downloads from their site. Keep the stable > >>> version far enough behind the development version that people will > >>> pay to get the newest code base. > >> > >> its really rather amusing to see people speculating on what the > >> developers of LS could or could not do, when the actual relevant > >> "encounter" with "commercial interests" has *already* happened. it did > >> not go well. it can be tempting to imagine that we understand the > >> motivations of commercial organizations and can therefore offer them > >> appropriate carrots. don't be so confident of this. both the LS > >> developers and myself are under the terms of an NDA, so it is not > >> possible to discuss with any relevant detail precisely what happened. > >> but it was nasty, it was unpleasant and as i've said before, it would > >> be better for people to not make so many assumptions about their ability > >> to guess at what might or might happen when a commercial company shows > >> interest in a tool like LS. > > > > Everyone can make assumptions about what they can or can't do until the > > cows come home, but it's irrelevant. The point it the license needs > > clarification. > > > > The disclaimer in the README is along the lines of what they intend to > > say (judging by the previously pasted quotes). The disclaimer on the > > webpage clearly makes it illegal to use LS on a CD you intend to sell, or > > in public concerts you sell tickets to (a goal that is specifically > > mentioned on the About page I might add), so if that isn't the intention > > it should be fixed. There is no disclaimer on the source files at all, so > > those are pure GPL with no commercial restrictions whatsoever. > > > > What IS the license to LinuxSampler? Who knows. They certainly havn't > > told us. > > > > We already know that the LS license is currently flawed. As Christian > wrote explicitly, even thought the README file still has the infamous > exception wording, *ALL* public releases of LinuxSampler until and > including 0.3.3 *ARE* plain GPL. That last public release was more than > one year ago. Since then, LinuxSampler code in CVS has changed in many > pervasive ways, and AFAICT for the better, performance and feature-wise. I think you're missing the point. Current CVS LS *IS* effectively GPLed. If a company wanted to use recent CVS LS in a commercial product right now, and did, there's no way you'd be able to do anything about it. There's a bunch of files in CVS that say right in them they're GPLed, and they point to a COPYING file which is the GPL, verbatim. There's not a lawyer in the world that would say a vague webpage disclaimer or README file (neither of which you actually need to see to get at the source code) overrides that. >From the sounds of it whatever company caused this isn't very friendly.. would you put it past them? You think you're covering your ass but you're not wearing any pants ;) > I strongly believe (although I'm also speculating here;) the next public > release of LinuxSampler, whenever it will be ready, will come with a > proper open-source license. And I pretty guess it will be pure GPL but I > just cannot garantee that yet ;) Cheers, -DR- From forest at alittletooquiet.net Tue Jul 4 14:18:28 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Tue Jul 4 14:18:39 2006 Subject: [linux-audio-dev] Re: fst, VST 2.0, kontakt In-Reply-To: References: <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> Message-ID: <20060704181828.GB15472@localdomain> > Something like specimen or probably much chionic is more suited. > Chionic is looking for new guys to help out if i remember right, help > them out, and you get what you want! ;) > > Loki Alright, I'm at least partially sold on chionic. I think that there are some usability concerns (for me, anyway), but the core features seem to be there. I would be happy to continue development (in one way or another). Anyone interested in helping? -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060704/34968a49/attachment.bin From mobarre at gmail.com Tue Jul 4 16:22:16 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jul 4 16:22:28 2006 Subject: [linux-audio-dev] Re: fst, VST 2.0, kontakt In-Reply-To: <20060704181828.GB15472@localdomain> References: <44A4AE0E.6000108@gmail.com> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <20060704181828.GB15472@localdomain> Message-ID: <3c808a150607041322m4ada12a8w8e2e546bc81a5578@mail.gmail.com> > > Alright, I'm at least partially sold on chionic. I think that there are some > usability concerns (for me, anyway), but the core features seem to be there. I > would be happy to continue development (in one way or another). > > Anyone interested in helping? > > -Forest I'll try the software first to see what it does exactly. seems my first job will be to get it to compile on my system. seeing the error message, I'll take a quick guess... gcc 4.1... Is the email you where writing from ok to tell you how things worked for me ? -- Marc-Olivier Barre, Kinoko en Orbite. From pshirkey at boosthardware.com Tue Jul 4 21:47:46 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Tue Jul 4 21:49:21 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1152017085.10662.136.camel@localhost.localdomain> References: <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <44A98352.7020407@boosthardware.com> <1151962269.6592.5.camel@c-d276e055.456-1-64736c13.cust.bredbandsbolaget.se> <1151963711.10662.112.camel@localhost.localdomain> <20060704102235.C6994@linus.it.uts.EDU.AU> <1151975344.10662.124.camel@localhost.localdomain> <44AA013B.9080508@ping.de> <1152017085.10662.136.camel@localhost.localdomain> Message-ID: <44AB1A42.40703@boosthardware.com> Paul Davis wrote: > On Tue, 2006-07-04 at 07:48 +0200, Andreas Kuckartz wrote: >> I have a simple question: >> >> Which companies are (or have been) distributing LinuxSampler as part of >> a package also including hardware and/or proprietary software? > > as noted liontracs do, and that means that is incumbent upon me to > stress that liontracs are *not* the commercial entity that i have > alluded to in my descriptions of what may or may not have taken place > with LS. > Of course not. There weren't any issues that came out of that "working" relationship. This mystery company has really got the better of us normal Linux Audio Devs... It's really strange that they would choose to abuse a fragile relationship and not expect us to take sides. I'll just go back to hitting myself in the forehead with a cork on a fork... Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From mobarre at gmail.com Wed Jul 5 01:51:07 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Wed Jul 5 01:51:18 2006 Subject: [linux-audio-dev] Call for all LA projects In-Reply-To: <000301c69e9a$210cd880$6602a8c0@64BitBadass> References: <000301c69e9a$210cd880$6602a8c0@64BitBadass> Message-ID: <3c808a150607042251o7cd53b18s7c462c379cf6593d@mail.gmail.com> On 7/3/06, Ivica Ico Bukvic wrote: > Linuxaudio.org is getting ready to announce new memberships in the coming > weeks. For this reason, I would like to invite all Linux Audio projects and > its members, as well as other allied projects, institutions, companies, and > hardware vendors to consider joining our organization. Is this a time limited opportunity or can one join whenever he is ready ? I am getting ready to launch an audio optimized distribution which is not quite ready yet, and I also have a bit of work on the home page. How much time do we have ? ______________ Marc-Olivier Barre, Kinoko en Orbite. From rncbc at rncbc.org Wed Jul 5 04:17:33 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Wed Jul 5 04:18:30 2006 Subject: LinuxSampler license, was Re: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1152035381.25105.16.camel@localhost.localdomain> References: <20060630003707.GE20075@storm.local.network> <20060630142504.GI20075@storm.local.network> <20060630145452.GD13275@teasel.arb.net> <1151764969.19306.0.camel@localhost.localdomain> <1151771666.19306.4.camel@localhost.localdomain> <44A6A881.8010902@boosthardware.com> <1151774570.7567.6.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> <44A6B3B2.3060408@boosthardware.com> <44A6D363.8020207@rncbc.org> <3c808a150607020227h356c029t4c7a35a1fc104bc6@mail.gmail.com> <44A7AFCB.2020505@rncbc.org> <44A7BAE9.1080500@woh.rr.com> <44A7F4B6.4000802@ping.de> <44A81285.4030301@woh.rr.com> <44A81DE0.7010705@boosthardware.com> <1151929990.10662.87.camel@localhost.localdomain> <1151963742.12737.25.camel@localhost.localdomain> <4895.213.58.131.130.1152001920.squirrel@www.rncbc.org> <1152035381.25105.16.camel@localhost.localdomain> Message-ID: <3067.195.245.190.94.1152087453.squirrel@www.rncbc.org> On Tue, July 4, 2006 18:49, Dave Robillard wrote: > On Tue, 2006-07-04 at 09:32 +0100, Rui Nuno Capela wrote: >> >> We already know that the LS license is currently flawed. As Christian >> wrote explicitly, even thought the README file still has the infamous >> exception wording, *ALL* public releases of LinuxSampler until and >> including 0.3.3 *ARE* plain GPL. That last public release was more than >> one year ago. Since then, LinuxSampler code in CVS has changed in many >> pervasive ways, and AFAICT for the better, performance and >> feature-wise. > > I think you're missing the point. Current CVS LS *IS* effectively > GPLed. > Reading straight from almost every LS source file headers, I guess you're right. GPL is the fundamental licensing terms of LS, and I think it will remain that way. My concern was only related to the LS core developers position regarding the issue Paul mentioned. Even tought I'm in the LS developer list, my main contribution took the form of Qsampler and liblscp, which are GPL and LGPL respectively. I must tell that I have little or almost no privileged information about the issue with the so-called "company". In fact, personally speaking of course, I don't give a damn, because all my work has been given just for fun. However ethically, I must give all the respect to every one of you and all others that have put something palatable of their lives at stake. Because they care. Cheers, -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From ico.bukvic at gmail.com Wed Jul 5 10:01:03 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Jul 5 10:01:16 2006 Subject: [linux-audio-dev] Call for all LA projects In-Reply-To: <3c808a150607042251o7cd53b18s7c462c379cf6593d@mail.gmail.com> Message-ID: <000b01c6a03b$7545a150$6602a8c0@64BitBadass> You are more than welcome to apply for membership at any time. However, the new members announcements happen on a more or less bimonthly basis simply for the sake of minimizing administrative overhead. Hope this helps! Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Marc-Olivier Barre > Sent: Wednesday, July 05, 2006 1:51 AM > To: The Linux Audio Developers' Mailing List > Cc: A list for linux audio users; consortium@lists.linuxaudio.org > Subject: Re: [linux-audio-dev] Call for all LA projects > > On 7/3/06, Ivica Ico Bukvic wrote: > > Linuxaudio.org is getting ready to announce new memberships in the > coming > > weeks. For this reason, I would like to invite all Linux Audio projects > and > > its members, as well as other allied projects, institutions, companies, > and > > hardware vendors to consider joining our organization. > > Is this a time limited opportunity or can one join whenever he is > ready ? I am getting ready to launch an audio optimized distribution > which is not quite ready yet, and I also have a bit of work on the > home page. How much time do we have ? > > ______________ > Marc-Olivier Barre, > Kinoko en Orbite. From smcameron at yahoo.com Wed Jul 5 10:27:25 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Jul 5 10:27:32 2006 Subject: [linux-audio-dev] Trying to build Om, Message-ID: <20060705142725.90069.qmail@web33003.mail.mud.yahoo.com> So, I'm trying to build Smack, which needs Om, which needs libgnomecanvasmm, which my os (Fedora Core 3) doesn't seem to have, so I found it here: http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ And when I try to build it, I get this: g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"libgnomecanvasmm\" -I../../libgnomecanvas -I../../libgnomecanvas -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/local/include/libart-2.0 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/atk-1.0 -I/usr/include/libgnomecanvas-2.0 -g -O2 -MT line.lo -MD -MP -MF .deps/line.Tpo -c line.cc -fPIC -DPIC -o .libs/line.o In file included from line.cc:3: ../../libgnomecanvas/libgnomecanvasmm/line.h:374: error: extra qualification ignored ../../libgnomecanvas/libgnomecanvasmm/line.h:375: error: explicit specialization of non-template `Glib::' ../../libgnomecanvas/libgnomecanvasmm/line.h:375: error: an anonymous union cannot have function members ../../libgnomecanvas/libgnomecanvasmm/line.h:378: error: abstract declarator `Glib::' used as declaration make[4]: *** [line.lo] Error 1 make[4]: Leaving directory `/home/scameron/software/libgnomecanvasmm-2.6.0/libgnomecanvas/libgnomecanvasmm' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/scameron/software/libgnomecanvasmm-2.6.0/libgnomecanvas/libgnomecanvasmm' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/scameron/software/libgnomecanvasmm-2.6.0/libgnomecanvas' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/scameron/software/libgnomecanvasmm-2.6.0/libgnomecanvas' make: *** [all-recursive] Error 1 [scameron@zuul libgnomecanvasmm-2.6.0]$ Anybody know how to get around this...? (without installing another OS preferably) -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From smcameron at yahoo.com Wed Jul 5 10:42:15 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Jul 5 10:42:43 2006 Subject: [linux-audio-dev] Trying to build Om, In-Reply-To: <20060705142725.90069.qmail@web33003.mail.mud.yahoo.com> Message-ID: <20060705144215.61120.qmail@web33002.mail.mud.yahoo.com> --- Stephen Cameron wrote: > > So, I'm trying to build Smack, which needs Om, which needs libgnomecanvasmm, > which my os (Fedora Core 3) doesn't seem to have, so I found it here: > http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ > > And when I try to build it, I get this: [...] > ../../libgnomecanvas/libgnomecanvasmm/line.h:374: error: extra qualification ignored > ../../libgnomecanvas/libgnomecanvasmm/line.h:375: error: explicit specialization of non-template > `Glib::' > ../../libgnomecanvas/libgnomecanvasmm/line.h:375: error: an anonymous union cannot have function > members > ../../libgnomecanvas/libgnomecanvasmm/line.h:378: error: abstract declarator `Glib:: \ { \ public: \ N(const T& v); \ }; It is fixed by replacing 'Property' by 'Property'. ------------ But, making that change did not help for me. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From smcameron at yahoo.com Wed Jul 5 11:19:05 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Jul 5 11:19:13 2006 Subject: [linux-audio-dev] Trying to build Om, In-Reply-To: <20060705144215.61120.qmail@web33002.mail.mud.yahoo.com> Message-ID: <20060705151905.24114.qmail@web33010.mail.mud.yahoo.com> > --- Stephen Cameron wrote: > > So, I'm trying to build Smack, which needs Om, which needs libgnomecanvasmm, > > which my os (Fedora Core 3) doesn't seem to have, so I found it here: > > http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ Nevermind, I found binary RPMs that seem to work. Sorry about making this noise on the list. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From niklas.kluegel at mytum.de Wed Jul 5 13:06:06 2006 From: niklas.kluegel at mytum.de (=?ISO-8859-1?Q?Niklas_Kl=FCgel?=) Date: Wed Jul 5 13:06:14 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? Message-ID: <44ABF17E.5070606@mytum.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oi, I am currently writing on a modular synth with great emphasis on sequencing (but allowing tight interaction between both parts) in a comparable modular way (pattern creation/algortihmic composition/chord filters etc), I wrote some parts of the core of the application but I am not really keen on coding something that has been done several times before; that's why I thought about joining/"forking" a more complete modular synthesizing environment and adding the core components I need/have. The point is, that I don't know enough about the existant modular synthesizers to evaluate how modular their sourcecode is written so that my modifications are easily applicable in their source. Here are some parts/functionalities that I already have (partially) implemented and would like to add to the core: - - the main graph of interconnected modules supports heterogene module types for example it could support FAUST code-pieces represented in modules as well as ladspa-modules, the subgraph created by interconnected modules of the same type is the sent to the type-specific "compiler" creating executable signal paths - - the executable graph of interconnected modules is analyzed and split up in parts that can be executed in parallel, locks in the necessary parts are added and the whole graph can be executed in several threads - - modules are mainly connected using a zoomable patch-matrix; the zoomlevel corresponds to the level of typing (of connections) As I mainly write QT-Applications I'd prefer a project that can be either easily extended to use QT or which already uses it. I think it is better to work on an existing project, since I am currently busy with releasing an album and university-shiznit and I can not imagine doing everything in a prolific way in parallel. Thanks in advance for any input! So long... Niklas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEq/F++k24EnBNzsMRAlNrAJ97l5nZeqM8B86w4FDrh34joLvZEQCeOxpn 1VD/QOT47Nfd2X6kEItBFRw= =jz9s -----END PGP SIGNATURE----- From pcoccoli at gmail.com Wed Jul 5 13:22:34 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Jul 5 13:22:41 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> <1151284988.16229.22.camel@localhost.localdomain> <20060626230543.GG10261@fitz.Belkin> Message-ID: <8d27a0610607051022p2d572cefx8c1c059f375b9ae1@mail.gmail.com> On 6/26/06, Jack O'Quin wrote: > OK, I see it now. All those uninitialized write complaints are due to > the fact that jack_request_t is a union. Most requests don't need (or > want) to fill in all the bytes, just the ones that matter for that > RequestType. > > There are jack_request_t structs used all over the place. The only > solution I can think of that would make valgrind happy would be to > initialize them all to zeroes before filling them in. While that would > eliminate these complaints, I have some doubts that we really want > to make all those changes. There is some risk of introducing real > bugs while fixing them. > > Those valgrind warnings really *are* annoying, of course. > -- > joq > Use valgrind's --gen-suppressions=yes option, create a suppressions file, and post it to the list for all to enjoy. From _ at whats-your.name Wed Jul 5 14:36:17 2006 From: _ at whats-your.name (carmen) Date: Wed Jul 5 14:36:32 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <44ABF17E.5070606@mytum.de> References: <44ABF17E.5070606@mytum.de> Message-ID: <20060705183617.GB3299@replic.net> On Wed Jul 05, 2006 at 07:06:06PM +0200, Niklas Kl?gel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Oi, > > I am currently writing on a modular synth with great emphasis on > sequencing (but allowing tight interaction between both parts) > in a comparable modular way (pattern creation/algortihmic > composition/chord filters etc), > I wrote some parts of the core of the application but I am not really > keen on coding something that has been done several times before; > that's why I thought about > joining/"forking" a more complete modular synthesizing environment and > adding the core components I need/have. The point is, that I don't > know enough about > the existant modular synthesizers to evaluate how modular their > sourcecode is written so that my modifications are easily applicable > in their source. > Here are some parts/functionalities that I already have (partially) > implemented and would like to add to the core: > - - the main graph of interconnected modules supports heterogene module > types for example it could support FAUST code-pieces represented in > modules as well as ladspa-modules, > the subgraph created by interconnected modules of the same type is the > sent to the type-specific "compiler" creating executable signal paths > - - the executable graph of interconnected modules is analyzed and split > up in parts that can be executed in parallel, locks in the necessary > parts are added and the whole graph can be > executed in several threads > - - modules are mainly connected using a zoomable patch-matrix; the > zoomlevel corresponds to the level of typing (of connections) this sound really neat. depending on how far along you are with your engine, you may want to keep it around, or someone else might want to pick it up. here are the active projects on linux: pd: crufty/crusty architecture, but lots of users and patches. C/SiBSD. the engine is being updated for a more modern client-server seperation, and 2 GUIs currently using this: DesireData (TCL/GPL), and Vibrez (OpenGL, commercial?) source: cvs -d:pserver:anonymous@pure-data.cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_39 pd pnpd: a new engine, from an expert user/contributor to PD who decided it would be easier to rewrite the engine than try to extend the existing codebase. C++/GPL, currently has a QT client called Karma. source: svn co svn://www.klingt.org/pnpd/ ingen: previously known as om-synth. only supports LADSPA & LV2 plugins. C++/Gnome-Canvas (Dave hates QT). theres an OSC API so you could easily roll your own frontend. currently LADSPA is really lacking in plugins that process MIDI/OSC, or mangle/record/playback any sort of control data, or even audio. it mainly has a ton of filters... source: svn co http://codeson.net/svn if you want to run your code on PD/MaxMSP and eventually pnpd, you can use flext (adding flext support to your own engine would give you a neat archive of existing objects, as well): source: cvs.pure-data.sourceforge.net:/cvsroot/pure-data/externals/grill/flext likewise, porting to LV2 will give you a lot of potential usage contexts (this is assuming the hosts add support): web: http://lv2plug.in i plan to put this into a semantic DB, for now you can check the massively incomplete http://wikifarm.koumbit.net/orangeseeds/drone/Meta/ComparatifLogicielsDataflow From _ at whats-your.name Wed Jul 5 14:44:09 2006 From: _ at whats-your.name (carmen) Date: Wed Jul 5 14:44:26 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <20060705183617.GB3299@replic.net> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> Message-ID: <20060705184409.GC3299@replic.net> > > sent to the type-specific "compiler" creating executable signal paths > > - - the executable graph of interconnected modules is analyzed and split > > up in parts that can be executed in parallel, locks in the necessary > > parts are added and the whole graph can be > > executed in several threads forgot Chuck. it has a VM and a 'strongly-timed' simultaneous execution model. theres an OpenGL GUI but no source code yet: http://chuck.cs.princeton.edu/ From niklas.kluegel at mytum.de Wed Jul 5 15:05:36 2006 From: niklas.kluegel at mytum.de (=?ISO-8859-1?Q?Niklas_Kl=FCgel?=) Date: Wed Jul 5 15:05:45 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <20060705184409.GC3299@replic.net> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> Message-ID: <44AC0D80.7050908@mytum.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 carmen wrote: >>> sent to the type-specific "compiler" creating executable signal >>> paths - - the executable graph of interconnected modules is >>> analyzed and split up in parts that can be executed in >>> parallel, locks in the necessary parts are added and the whole >>> graph can be executed in several threads > > forgot Chuck. it has a VM and a 'strongly-timed' simultaneous > execution model. theres an OpenGL GUI but no source code yet: > http://chuck.cs.princeton.edu/ wow, thanks! I am going to look into the source of the projects the next days, currently pnpd triggers most of my attention. so long... Niklas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFErA2A+k24EnBNzsMRArnvAJ0f2b5pr5ahJAhJWxSQNa9JMUhueQCcC8Gm edO8xFkv5dDkeHzorQwUu18= =Nn/E -----END PGP SIGNATURE----- From drobilla at connect.carleton.ca Wed Jul 5 15:44:49 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Jul 5 15:44:58 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <20060705183617.GB3299@replic.net> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> Message-ID: <1152128689.10983.11.camel@localhost.localdomain> On Wed, 2006-07-05 at 18:36 +0000, carmen wrote: > On Wed Jul 05, 2006 at 07:06:06PM +0200, Niklas Kl?gel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Oi, > > > > I am currently writing on a modular synth with great emphasis on > > sequencing (but allowing tight interaction between both parts) > > in a comparable modular way (pattern creation/algortihmic > > composition/chord filters etc), > > I wrote some parts of the core of the application but I am not really > > keen on coding something that has been done several times before; > > that's why I thought about > > joining/"forking" a more complete modular synthesizing environment and > > adding the core components I need/have. The point is, that I don't > > know enough about > > the existant modular synthesizers to evaluate how modular their > > sourcecode is written so that my modifications are easily applicable > > in their source. > > Here are some parts/functionalities that I already have (partially) > > implemented and would like to add to the core: > > - - the main graph of interconnected modules supports heterogene module > > types for example it could support FAUST code-pieces represented in > > modules as well as ladspa-modules, > > the subgraph created by interconnected modules of the same type is the > > sent to the type-specific "compiler" creating executable signal paths > > - - the executable graph of interconnected modules is analyzed and split > > up in parts that can be executed in parallel, locks in the necessary > > parts are added and the whole graph can be > > executed in several threads > > - - modules are mainly connected using a zoomable patch-matrix; the > > zoomlevel corresponds to the level of typing (of connections) > > this sound really neat. depending on how far along you are with your engine, you may want to keep it around, or someone else might want to pick it up. here are the active projects on linux: [snip] > ingen: previously known as om-synth. only supports LADSPA & LV2 plugins. C++/Gnome-Canvas (Dave hates QT). theres an OSC API so you could easily roll your own frontend. currently LADSPA is really lacking in plugins that process MIDI/OSC, or mangle/record/playback any sort of control data, or even audio. it mainly has a ton of filters... > source: svn co http://codeson.net/svn LV2 should hopefully solve these limitations Om/Ingen suffered at the hands of LADSPA. MIDI processing plugins will be available, and making samplers and loopers and all that fun stuff LADSPA isn't very good at should be more feasible. Ingen isn't going to progress much in the next month or two though, I'm busy in Ardour-land... The graph is "compiled" in a sense - it's traversed to generate a flat array that is actually executed in the process callback, so generating some parallel-executable structure instead of an array is doable without any major changes. There's no parallelism right now mostly because I don't think it's possible to do so and have the process callback still be hard realtime (anyone with an idea otherwise please let me know). That said, feel free to take a look. "Node" (src/libs/engine/Node.h) is the important (pure abstract) interface. Anything that implements that can run in a patch (graph). so faust support or whatever should be easy (in the case of compiled stuff like Faust the compilation would happen inside the Node class unbeknownst to everything else). I did LV2 support in a half hour, it's not difficult to add new Node types. Drop me a line via email or IRC if it looks like something you can work with. Cheers, -DR- From stefan at space.twc.de Wed Jul 5 19:03:53 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Wed Jul 5 18:24:20 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <44ABF17E.5070606@mytum.de> References: <44ABF17E.5070606@mytum.de> Message-ID: <20060705230353.GA4592@space.twc.de> Hi! On Wed, Jul 05, 2006 at 07:06:06PM +0200, Niklas Kl?gel wrote: > I am currently writing on a modular synth with great emphasis on > sequencing (but allowing tight interaction between both parts) > in a comparable modular way (pattern creation/algortihmic > composition/chord filters etc), Well, beast (http://beast.gtk.org) is a modular synthesis environment with integrated sequencer. However, the sequencing part is not as modular as the synthesis part; as this seems to be a central idea for you, you'd need to write the code for that. > As I mainly write QT-Applications I'd prefer a project that can be > either easily extended to use QT or which already uses it. I think it > is better to work on an existing project, since > I am currently busy with releasing an album and university-shiznit and > I can not imagine doing everything in a prolific way in parallel. If you prefer QT because it is C++: we're slowly migrating stuff from C to C++. The GUI of beast is Gtk+, though. However, the separation between synthesis code and GUI code is rather clean, so you could implement a Qt C++ GUI on top of the existing synthesis/sequencing code, if you really wanted to. And yes, I think unless you have a few years to spend only on coding your project, I'd recommend working on some existing project, since writing a modular synthesis app and sequencing and a good gui is a lot of work. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From loki.davison at gmail.com Wed Jul 5 19:06:56 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Jul 5 19:07:03 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060705151905.24114.qmail@web33010.mail.mud.yahoo.com> References: <20060705144215.61120.qmail@web33002.mail.mud.yahoo.com> <20060705151905.24114.qmail@web33010.mail.mud.yahoo.com> Message-ID: On 7/6/06, Stephen Cameron wrote: > > --- Stephen Cameron wrote: > > > So, I'm trying to build Smack, which needs Om, which needs > libgnomecanvasmm, > > > which my os (Fedora Core 3) doesn't seem to have, so I found it here: > > > > http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ > > Nevermind, I found binary RPMs that seem to work. > Sorry about making this noise on the list. > > -- steve > Hearing some noise about anyone trying to use smack/om is a good thing ;) I am sorry about the some what limited smack docs.... If you have any probs feel free to ask. If you find any solutions feel free to put them on the smack or om wiki ;) Loki From a at gaydenko.com Wed Jul 5 21:02:23 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Wed Jul 5 21:02:49 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <1182.192.168.1.13.1151910475.squirrel@www.infotecna.lcl> References: <200606241915.38534@goldspace.net> <200607021857.57787@goldspace.net> <1182.192.168.1.13.1151910475.squirrel@www.infotecna.lcl> Message-ID: <200607060502.23982@goldspace.net> ======= On Monday 03 July 2006 11:07, Denis Sbragion wrote: ======= Hello Andrew, ... See the Mourjopoulos papers for further details. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it ====================================================================================== Denis, I have not found free description of the method defined in this article: P.Hatziantoniou,J.Mourjopoulos,"Generalized Fractional-Octave Smoothing of Audio and Acoustic Responses", Journal of the Audio Engineering Society, Vol. 48, No. 4, pp. 259 - 280, April 2000. At any case, I have tried very simple smoothing of FFT-output, when y(n) is an arithmetic mean of x(n) and few other input signals before x(n). This "few other" is proportional to n. Result of "1/6 octave smoothing" is here: http://gaydenko.com/mix/simpleSmoothing.png "For eyes", the result is absolutely appropriate for my audio-DIY-ing purposes. Probably, shown below short python fragment is better rather my ugly English. The fragment is applied just after FFT-ing (i.e., before converting to db). Andrew =============================== import Numeric def smooth( x, # real octaveFraction = 1.01 # for "1/3 octave smoothing" # this par is supposed to be a pow(2.0, 1.0/3.0) ): y = [] for n in range(len(x)): sum = x[n] meanLength = int( (octaveFraction - 1.0) * n / 2.0 ) if meanLength > 0: for k in range(meanLength): idx = n - k if(idx < 0): idx = 0 # to avoid edge effect sum += x[idx] y.append(sum / (meanLength + 1)) return Numeric.array(y) From smcameron at yahoo.com Wed Jul 5 23:41:49 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Jul 5 23:41:57 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: Message-ID: <20060706034149.54592.qmail@web33006.mail.mud.yahoo.com> --- Loki Davison wrote: > On 7/6/06, Stephen Cameron wrote: > > > --- Stephen Cameron wrote: > > > > So, I'm trying to build Smack, which needs Om, which needs > > libgnomecanvasmm, > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it here: > > > > > > http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ > > > > Nevermind, I found binary RPMs that seem to work. > > Sorry about making this noise on the list. > > > > -- steve > > > > Hearing some noise about anyone trying to use smack/om is a good thing Yeah, I know what you mean. Sourceforge reports over 1000 downloads of my gneutronica, but I have about 2 people I know of who I know have actually attempted to use it. I find myself wondering if the other 998 are just robots that download whatever appears on sourceforge. I have gotten zero contributions in terms of code or even bug reports... on the bright side, I've had to deal with zero bug reports, or patches that don't work or are otherwise insane, LOL. Well, I can hardly complain about lack of code contributions. Before I started this, I looked instead to try to make Hydrogen do what I wanted, but there was so much code, and it was so incomprehensible and foreign to me, it was easier to just write my own, and, doing that allowed me to learn as I went, at my own pace, so it has been satisfying, even if I am the only real user of my program. > ;) I am sorry about the some what limited smack docs.... If you have > any probs feel free to ask. If you find any solutions feel free to put > them on the smack or om wiki ;) Actually, the binary rpms I found didn't work out after all. They allowed me to build everything, but... I tried to start om_gtk... First it complained about not being able to find libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 Now, it complains... [scameron@zuul ~]$ om_gtk [StateManager] Unable to open settings file /home/scameron/.omgtkrc (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for class `gtkmm__GtkWindow' (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for class `gtkmm__GtkLabel' (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' for class `gtkmm__GtkLabel' (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class `gtkmm__GtkLabel' (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' And finally, it dies with a bunch of crap like this: ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): dynamic_cast<> failed. So I guess I don't yet have the right libgnomecanvasmm, or libglade*so* or something for Fedora Core 3... Ah, well, it's all part of this great, very intellectual video game I've been playing for the last year called "Linux Audio Adventure." -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From smcameron at yahoo.com Wed Jul 5 23:55:05 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Wed Jul 5 23:55:15 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: Message-ID: <20060706035505.59004.qmail@web33006.mail.mud.yahoo.com> I wrote: > I have gotten zero contributions in terms of code or > even bug reports... [ for gneutronica ] On second thought, this is not quite true, and not wishing to slight anyone, I thought I had better correct myself. Someone diligently produces RPMs from my source releases for several distros of their own volition (thanks oc2pus) and a couple people noticed my last release had a broken tar.gz file right away. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From loki.davison at gmail.com Thu Jul 6 01:16:05 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 6 01:16:13 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060706035505.59004.qmail@web33006.mail.mud.yahoo.com> References: <20060706035505.59004.qmail@web33006.mail.mud.yahoo.com> Message-ID: On 7/6/06, Stephen Cameron wrote: > I wrote: > > > I have gotten zero contributions in terms of code or > > even bug reports... [ for gneutronica ] > > On second thought, this is not quite true, and not wishing to > slight anyone, I thought I had better correct myself. Someone > diligently produces RPMs from my source releases for several > distros of their own volition (thanks oc2pus) and a couple > people noticed my last release had a broken tar.gz file > right away. > > -- steve > The oc2pus guys do the same for smack! ;) and phat and khagan! I've also had thorsten contributing lots of stuff but not anyone i didn't know from irc. From d.sbragion at infotecna.it Thu Jul 6 03:19:16 2006 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Thu Jul 6 03:19:32 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <200607060502.23982@goldspace.net> References: <200606241915.38534@goldspace.net> <200607021857.57787@goldspace.net> <1182.192.168.1.13.1151910475.squirrel@www.infotecna.lcl> <200607060502.23982@goldspace.net> Message-ID: <1111.192.168.1.13.1152170356.squirrel@www.infotecna.lcl> Hello Andrew, On Thu, July 6, 2006 03:02, Andrew Gaydenko wrote: > At any case, I have tried very simple smoothing of FFT-output, when y(n) is an > arithmetic mean > of x(n) and few other input signals before x(n). This "few other" is > proportional to n. Result > of "1/6 octave smoothing" is here: > > http://gaydenko.com/mix/simpleSmoothing.png ... this looks pretty much like the classical "running average" smoothing, which is one of the standard methods used to perform fractional octave smoothing. For most purposes this is pretty good. BTW there's one thing that is unclear to me: ... > if(idx < 0): idx = 0 # to avoid edge effect > sum += x[idx] ... Here x[idx] is a complex value or a real one (i.e. magnitude only)? If it's a real one you're doing the standard fractional octave smoothing, if it is a complex one you're doing something pretty close to complex smoothing. Looking at the results it should be a real value, else there should be the typical phase cancellation problems of the complex smoothing procedure. There are some way to overcome these problems. I have a paper where smothing is performed separately on the magnitude and phase of the response. The results are really good in this situation, as long as you are able to compute the continuous (unwrapped) phase function, which is a challenging task by itself. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From drobilla at connect.carleton.ca Thu Jul 6 03:34:24 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Jul 6 03:34:48 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060706034149.54592.qmail@web33006.mail.mud.yahoo.com> References: <20060706034149.54592.qmail@web33006.mail.mud.yahoo.com> Message-ID: <1152171264.15427.4.camel@localhost.localdomain> On Wed, 2006-07-05 at 20:41 -0700, Stephen Cameron wrote: > > --- Loki Davison wrote: > > > On 7/6/06, Stephen Cameron wrote: > > > > --- Stephen Cameron wrote: > > > > > So, I'm trying to build Smack, which needs Om, which needs > > > libgnomecanvasmm, > > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it here: > > > > > > > > http://sunsite.mff.cuni.cz/MIRRORS/ftp.gnome.org/pub/GNOME/sources/libgnomecanvasmm/2.6/ > > > > > > Nevermind, I found binary RPMs that seem to work. > > > Sorry about making this noise on the list. > > > > > > -- steve > > > > > > > Hearing some noise about anyone trying to use smack/om is a good thing > > Yeah, I know what you mean. Sourceforge reports over 1000 downloads of > my gneutronica, but I have about 2 people I know of who I know have actually > attempted to use it. I find myself wondering if the other 998 are just > robots that download whatever appears on sourceforge. I have gotten zero > contributions in terms of code or even bug reports... on the bright side, > I've had to deal with zero bug reports, or patches that don't work or are > otherwise insane, LOL. > > Well, I can hardly complain about lack of code contributions. Before > I started this, I looked instead to try to make Hydrogen do what I wanted, > but there was so much code, and it was so incomprehensible and foreign > to me, it was easier to just write my own, and, doing that allowed me to > learn as I went, at my own pace, so it has been satisfying, even if I am > the only real user of my program. > > > ;) I am sorry about the some what limited smack docs.... If you have > > any probs feel free to ask. If you find any solutions feel free to put > > them on the smack or om wiki ;) > > Actually, the binary rpms I found didn't work out after all. > They allowed me to build everything, but... > > I tried to start om_gtk... First it complained about not being able to find > libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) > > ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 > > Now, it complains... > > [scameron@zuul ~]$ om_gtk > [StateManager] Unable to open settings file /home/scameron/.omgtkrc > (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for class `gtkmm__GtkWindow' > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' > (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for class `gtkmm__GtkLabel' > (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' for class > `gtkmm__GtkLabel' > (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class `gtkmm__GtkLabel' > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' > > And finally, it dies with a bunch of crap like this: > > ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): dynamic_cast<> failed. > > So I guess I don't yet have the right libgnomecanvasmm, > or libglade*so* or something for Fedora Core 3... Looks like your GTK/GTKmm version is too old. (Actually since you're using FC3, I'd bet the farm on it. A while back some crazy idiot complained about my dependency on a Gtk version that'd been out as a stable release for almost 2 years because Fedora was so on the ball... :) ) The configure script should have stopped you from building it though, odd. What version of gtkmm? -DR- From a at gaydenko.com Thu Jul 6 08:03:24 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Jul 6 08:04:13 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <1111.192.168.1.13.1152170356.squirrel@www.infotecna.lcl> References: <200606241915.38534@goldspace.net> <200607060502.23982@goldspace.net> <1111.192.168.1.13.1152170356.squirrel@www.infotecna.lcl> Message-ID: <200607061603.24908@goldspace.net> ======= On Thursday 06 July 2006 11:19, Denis Sbragion wrote: ======= Hello Andrew, ... this looks pretty much like the classical "running average" smoothing, which is one of the standard methods used to perform fractional octave smoothing. For most purposes this is pretty good. BTW there's one thing that is unclear to me: ... > if(idx < 0): idx = 0 # to avoid edge effect > sum += x[idx] ... Here x[idx] is a complex value or a real one (i.e. magnitude only)? If it's a real one you're doing the standard fractional octave smoothing, if it is a complex one you're doing something pretty close to complex smoothing. Looking at the results it should be a real value, else there should be the typical phase cancellation problems of the complex smoothing procedure. There are some way to overcome these problems. I have a paper where smothing is performed separately on the magnitude and phase of the response. The results are really good in this situation, as long as you are able to compute the continuous (unwrapped) phase function, which is a challenging task by itself. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it ================================================================================= Denis, x[n] is real (abs() of the FFT result). It is interesting, I still have not found any article about fractional octave smoothing. All googling results lead to cited AES article. So, applied smoothing is as an "invention" for me :-) Is your paper about smoothing free? Andrew From smcameron at yahoo.com Thu Jul 6 08:24:10 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Thu Jul 6 08:24:17 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <1152171264.15427.4.camel@localhost.localdomain> Message-ID: <20060706122410.63795.qmail@web33011.mail.mud.yahoo.com> --- Dave Robillard wrote: > On Wed, 2006-07-05 at 20:41 -0700, Stephen Cameron wrote: > > > > --- Loki Davison wrote: > > > > > On 7/6/06, Stephen Cameron wrote: > > > > > --- Stephen Cameron wrote: > > > > > > So, I'm trying to build Smack, which needs Om, which needs > > > > libgnomecanvasmm, > > > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it here: [...] > > I tried to start om_gtk... First it complained about not being able to find > > libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) > > > > ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 > > > > Now, it complains... > > > > [scameron@zuul ~]$ om_gtk > > [StateManager] Unable to open settings file /home/scameron/.omgtkrc > > (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for class > `gtkmm__GtkWindow' > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' > > (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for class `gtkmm__GtkLabel' > > (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' for class > > `gtkmm__GtkLabel' > > (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class `gtkmm__GtkLabel' > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for class `gtkmm__GtkLabel' > > > > And finally, it dies with a bunch of crap like this: > > > > ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): dynamic_cast<> failed. > > > > So I guess I don't yet have the right libgnomecanvasmm, > > or libglade*so* or something for Fedora Core 3... > > Looks like your GTK/GTKmm version is too old. (Actually since you're > using FC3, I'd bet the farm on it. A while back some crazy idiot > complained about my dependency on a Gtk version that'd been out as a > stable release for almost 2 years because Fedora was so on the > ball... :) ) > > The configure script should have stopped you from building it though, > odd. What version of gtkmm? > > -DR- > > [scameron@zuul software]$ rpm -qa | grep gtkmm gtkmm24-2.4.11-1 gtkmm24-devel-2.4.11-1 gtkmm24-docs-2.4.11-1 And just to check in case I built it from source without telling RPM... [scameron@zuul software]$ ls -ld /usr/lib/libgtkmm* -rw-r--r-- 1 root root 4127910 May 11 2005 /usr/lib/libgtkmm-2.4.a lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so -> libgtkmm-2.4.so.1.0.11 lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so.1 -> libgtkmm-2.4.so.1.0.11 -rwxr-xr-x 1 root root 2517840 May 11 2005 /usr/lib/libgtkmm-2.4.so.1.0.11 [scameron@zuul software]$ Hmm, looking at gtk.org, I see gtk and friends churn quite a lot. I foresee hours and hours of downloading in my future. Should I grab gtk 2.8 + dependencies? -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From d.sbragion at infotecna.it Thu Jul 6 08:56:59 2006 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Thu Jul 6 08:57:15 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <200607061603.24908@goldspace.net> References: <200606241915.38534@goldspace.net> <200607060502.23982@goldspace.net> <1111.192.168.1.13.1152170356.squirrel@www.infotecna.lcl> <200607061603.24908@goldspace.net> Message-ID: <1990.192.168.1.13.1152190619.squirrel@www.infotecna.lcl> Hello Andrew, On Thu, July 6, 2006 14:03, Andrew Gaydenko wrote: > x[n] is real (abs() of the FFT result). It is interesting, I still have not > found any > article about fractional octave smoothing. All googling results lead to cited > AES article. > So, applied smoothing is as an "invention" for me :-) I suspect it is an invention for almost everyone... :) There's little documentation about the common smoothing procedures used in audio. Most of the available papers have been written after the Mourjopoulos ones. A better analysis of the effects of smoothing has been started because an accurate smoothing procedure of the complex response is needed for digital room correction purposes. Before this it was pretty much just trickery used to make the results easier to read to our eyes. > Is your paper about smoothing free? "The use of continuous phase for interpolation, smoothing and forming mean values of complex frequency response curves" It is available here: http://www.randteam.de/papers_jp/aes116_The_use_of_continuous_phase-JP.pdf Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From loki.davison at gmail.com Thu Jul 6 18:57:23 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 6 18:57:31 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060706122410.63795.qmail@web33011.mail.mud.yahoo.com> References: <1152171264.15427.4.camel@localhost.localdomain> <20060706122410.63795.qmail@web33011.mail.mud.yahoo.com> Message-ID: On 7/6/06, Stephen Cameron wrote: > --- Dave Robillard wrote: > > > On Wed, 2006-07-05 at 20:41 -0700, Stephen Cameron wrote: > > > > > > --- Loki Davison wrote: > > > > > > > On 7/6/06, Stephen Cameron wrote: > > > > > > --- Stephen Cameron wrote: > > > > > > > So, I'm trying to build Smack, which needs Om, which needs > > > > > libgnomecanvasmm, > > > > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it > here: > [...] > > > I tried to start om_gtk... First it complained about not being able to > find > > > libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) > > > > > > ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 > > > > > > Now, it complains... > > > > > > [scameron@zuul ~]$ om_gtk > > > [StateManager] Unable to open settings file /home/scameron/.omgtkrc > > > (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for > class > > `gtkmm__GtkWindow' > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > class `gtkmm__GtkLabel' > > > (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for > class `gtkmm__GtkLabel' > > > (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' > for class > > > `gtkmm__GtkLabel' > > > (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class > `gtkmm__GtkLabel' > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > class `gtkmm__GtkLabel' > > > > > > And finally, it dies with a bunch of crap like this: > > > > > > ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): > dynamic_cast<> failed. > > > > > > So I guess I don't yet have the right libgnomecanvasmm, > > > or libglade*so* or something for Fedora Core 3... > > > > Looks like your GTK/GTKmm version is too old. (Actually since you're > > using FC3, I'd bet the farm on it. A while back some crazy idiot > > complained about my dependency on a Gtk version that'd been out as a > > stable release for almost 2 years because Fedora was so on the > > ball... :) ) > > > > The configure script should have stopped you from building it though, > > odd. What version of gtkmm? > > > > -DR- > > > > > [scameron@zuul software]$ rpm -qa | grep gtkmm > gtkmm24-2.4.11-1 > gtkmm24-devel-2.4.11-1 > gtkmm24-docs-2.4.11-1 > > And just to check in case I built it from source without telling RPM... > > [scameron@zuul software]$ ls -ld /usr/lib/libgtkmm* > -rw-r--r-- 1 root root 4127910 May 11 2005 /usr/lib/libgtkmm-2.4.a > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so -> > libgtkmm-2.4.so.1.0.11 > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so.1 -> > libgtkmm-2.4.so.1.0.11 > -rwxr-xr-x 1 root root 2517840 May 11 2005 /usr/lib/libgtkmm-2.4.so.1.0.11 > [scameron@zuul software]$ > > Hmm, looking at gtk.org, I see gtk and friends churn quite a lot. > I foresee hours and hours of downloading in my future. > > Should I grab gtk 2.8 + dependencies? > > -- steve It doesn't take that long to build it all from source, it might be easier to do some kind of upgrade/update/distupdate of your distro instead. Can you just change where your apt-get/whatever sources are pointed at and then upgrade easily. I've done this many times over many years with mandriva and never had a problem. Loki From smcameron at yahoo.com Thu Jul 6 23:20:44 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Thu Jul 6 23:20:52 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: Message-ID: <20060707032044.721.qmail@web33007.mail.mud.yahoo.com> --- Loki Davison wrote: > On 7/6/06, Stephen Cameron wrote: > > --- Dave Robillard wrote: > > > > > On Wed, 2006-07-05 at 20:41 -0700, Stephen Cameron wrote: > > > > > > > > --- Loki Davison wrote: > > > > > > > > > On 7/6/06, Stephen Cameron wrote: > > > > > > > --- Stephen Cameron wrote: > > > > > > > > So, I'm trying to build Smack, which needs Om, which needs > > > > > > libgnomecanvasmm, > > > > > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it > > here: > > [...] > > > > I tried to start om_gtk... First it complained about not being able to > > find > > > > libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) > > > > > > > > ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 > > > > > > > > Now, it complains... > > > > > > > > [scameron@zuul ~]$ om_gtk > > > > [StateManager] Unable to open settings file /home/scameron/.omgtkrc > > > > (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for > > class > > > `gtkmm__GtkWindow' > > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > > class `gtkmm__GtkLabel' > > > > (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for > > class `gtkmm__GtkLabel' > > > > (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' > > for class > > > > `gtkmm__GtkLabel' > > > > (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class > > `gtkmm__GtkLabel' > > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > > class `gtkmm__GtkLabel' > > > > > > > > And finally, it dies with a bunch of crap like this: > > > > > > > > ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): > > dynamic_cast<> failed. > > > > > > > > So I guess I don't yet have the right libgnomecanvasmm, > > > > or libglade*so* or something for Fedora Core 3... > > > > > > Looks like your GTK/GTKmm version is too old. (Actually since you're > > > using FC3, I'd bet the farm on it. A while back some crazy idiot > > > complained about my dependency on a Gtk version that'd been out as a > > > stable release for almost 2 years because Fedora was so on the > > > ball... :) ) > > > > > > The configure script should have stopped you from building it though, > > > odd. What version of gtkmm? > > > > > > -DR- > > > > > > > > [scameron@zuul software]$ rpm -qa | grep gtkmm > > gtkmm24-2.4.11-1 > > gtkmm24-devel-2.4.11-1 > > gtkmm24-docs-2.4.11-1 > > > > And just to check in case I built it from source without telling RPM... > > > > [scameron@zuul software]$ ls -ld /usr/lib/libgtkmm* > > -rw-r--r-- 1 root root 4127910 May 11 2005 /usr/lib/libgtkmm-2.4.a > > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so -> > > libgtkmm-2.4.so.1.0.11 > > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so.1 -> > > libgtkmm-2.4.so.1.0.11 > > -rwxr-xr-x 1 root root 2517840 May 11 2005 /usr/lib/libgtkmm-2.4.so.1.0.11 > > [scameron@zuul software]$ > > > > Hmm, looking at gtk.org, I see gtk and friends churn quite a lot. > > I foresee hours and hours of downloading in my future. > > > > Should I grab gtk 2.8 + dependencies? > > > > -- steve > > It doesn't take that long to build it all from source, it might be > easier to do some kind of upgrade/update/distupdate of your distro > instead. Can you just change where your apt-get/whatever sources are > pointed at and then upgrade easily. I've done this many times over > many years with mandriva and never had a problem. > > Loki > Actually, I already built it from source this morning, but, still no go... All these from gtk.org: * Installed cairo-1.2.0 * Installed glib-2.6.6 ... it went into /usr/local/lib * set LD_LIBRARY_PATH, PKG_CONFIG_PATH to include /usr/local/lib... * Installed atk-1.9.0 * Installed pango-1.8.2 * Installed gtk-2.6.10 Reconfigured om... noticed it complained about lash not being found... * Installed lash-0.5.1 from http://www.nongnu.org/lash/ Reconfigured om-, and recompiled and installed. Still complains about the glade stuff as before. I didn't rebuild libgnomecanvasmm though, because there seems to be some compiler problem, it seems. Maybe I have to upgrade gcc? I have: gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Maybe I can't have those libs in /usr/local/lib, but must have them in /usr/lib? -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From _ at whats-your.name Fri Jul 7 00:36:07 2006 From: _ at whats-your.name (carmen) Date: Fri Jul 7 00:36:29 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060707032044.721.qmail@web33007.mail.mud.yahoo.com> References: <20060707032044.721.qmail@web33007.mail.mud.yahoo.com> Message-ID: <20060707043607.GH13056@replic.net> > > All these from gtk.org: > > * Installed cairo-1.2.0 > * Installed glib-2.6.6 ... it went into /usr/local/lib > * set LD_LIBRARY_PATH, PKG_CONFIG_PATH to include /usr/local/lib... > * Installed atk-1.9.0 > * Installed pango-1.8.2 > * Installed gtk-2.6.10 > > Reconfigured om... noticed it complained about lash not being found... > > * Installed lash-0.5.1 from http://www.nongnu.org/lash/ > > Reconfigured om-, and recompiled and installed. > Still complains about the glade stuff as before. > > I didn't rebuild libgnomecanvasmm though, because there > seems to be some compiler problem, it seems. from om-cvs ebuild: DEPEND=">=media-libs/liblo-0.22 >=media-sound/jack-audio-connection-kit-0.99 >=dev-libs/libxml2-2.6 media-libs/dssi media-libs/ladspa-sdk media-plugins/omins >=dev-cpp/gtkmm-2.4 >=dev-cpp/libgnomecanvasmm-2.6 >=dev-cpp/libglademm-2.4.1 >=media-libs/flowcanvas-0.1.0 lash? ( media-sound/lash ) dssi? ( media-libs/dssi ) !media-sound/om" as other users suggested, i'd update your distro to the current version. if it still doesnt have the above dependencies , id switch to a distro that does. debian and gentoo are two good options... probably arch and mandrake as well.. From drobilla at connect.carleton.ca Fri Jul 7 00:44:23 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Jul 7 00:45:03 2006 Subject: [linux-audio-dev] Re: Trying to build Om, In-Reply-To: <20060707032044.721.qmail@web33007.mail.mud.yahoo.com> References: <20060707032044.721.qmail@web33007.mail.mud.yahoo.com> Message-ID: <1152247463.23251.4.camel@localhost.localdomain> On Thu, 2006-07-06 at 20:20 -0700, Stephen Cameron wrote: > > --- Loki Davison wrote: > > > On 7/6/06, Stephen Cameron wrote: > > > --- Dave Robillard wrote: > > > > > > > On Wed, 2006-07-05 at 20:41 -0700, Stephen Cameron wrote: > > > > > > > > > > --- Loki Davison wrote: > > > > > > > > > > > On 7/6/06, Stephen Cameron wrote: > > > > > > > > --- Stephen Cameron wrote: > > > > > > > > > So, I'm trying to build Smack, which needs Om, which needs > > > > > > > libgnomecanvasmm, > > > > > > > > > which my os (Fedora Core 3) doesn't seem to have, so I found it > > > here: > > > [...] > > > > > I tried to start om_gtk... First it complained about not being able to > > > find > > > > > libgnomecanvasmm.2.6.so.1, so, try (in /usr/lib) > > > > > > > > > > ln -s libgnomecanvasmm-2.6.so.1.0.1 libgnomecanvasmm-2.6.so.1 > > > > > > > > > > Now, it complains... > > > > > > > > > > [scameron@zuul ~]$ om_gtk > > > > > [StateManager] Unable to open settings file /home/scameron/.omgtkrc > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `focus_on_map' for > > > class > > > > `gtkmm__GtkWindow' > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > > > class `gtkmm__GtkLabel' > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `width_chars' for > > > class `gtkmm__GtkLabel' > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `single_line_mode' > > > for class > > > > > `gtkmm__GtkLabel' > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `angle' for class > > > `gtkmm__GtkLabel' > > > > > (om_gtk:2173): libglade-WARNING **: unknown property `ellipsize' for > > > class `gtkmm__GtkLabel' > > > > > > > > > > And finally, it dies with a bunch of crap like this: > > > > > > > > > > ** (om_gtk:2173): CRITICAL **: Gnome::Glade::Xml::get_widget(): > > > dynamic_cast<> failed. > > > > > > > > > > So I guess I don't yet have the right libgnomecanvasmm, > > > > > or libglade*so* or something for Fedora Core 3... > > > > > > > > Looks like your GTK/GTKmm version is too old. (Actually since you're > > > > using FC3, I'd bet the farm on it. A while back some crazy idiot > > > > complained about my dependency on a Gtk version that'd been out as a > > > > stable release for almost 2 years because Fedora was so on the > > > > ball... :) ) > > > > > > > > The configure script should have stopped you from building it though, > > > > odd. What version of gtkmm? > > > > > > > > -DR- > > > > > > > > > > > [scameron@zuul software]$ rpm -qa | grep gtkmm > > > gtkmm24-2.4.11-1 > > > gtkmm24-devel-2.4.11-1 > > > gtkmm24-docs-2.4.11-1 > > > > > > And just to check in case I built it from source without telling RPM... > > > > > > [scameron@zuul software]$ ls -ld /usr/lib/libgtkmm* > > > -rw-r--r-- 1 root root 4127910 May 11 2005 /usr/lib/libgtkmm-2.4.a > > > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so -> > > > libgtkmm-2.4.so.1.0.11 > > > lrwxrwxrwx 1 root root 22 Jun 17 12:14 /usr/lib/libgtkmm-2.4.so.1 -> > > > libgtkmm-2.4.so.1.0.11 > > > -rwxr-xr-x 1 root root 2517840 May 11 2005 /usr/lib/libgtkmm-2.4.so.1.0.11 > > > [scameron@zuul software]$ > > > > > > Hmm, looking at gtk.org, I see gtk and friends churn quite a lot. > > > I foresee hours and hours of downloading in my future. > > > > > > Should I grab gtk 2.8 + dependencies? > > > > > > -- steve > > > > It doesn't take that long to build it all from source, it might be > > easier to do some kind of upgrade/update/distupdate of your distro > > instead. Can you just change where your apt-get/whatever sources are > > pointed at and then upgrade easily. I've done this many times over > > many years with mandriva and never had a problem. > > > > Loki > > > > Actually, I already built it from source this morning, but, still no go... > > All these from gtk.org: > > * Installed cairo-1.2.0 > * Installed glib-2.6.6 ... it went into /usr/local/lib > * set LD_LIBRARY_PATH, PKG_CONFIG_PATH to include /usr/local/lib... > * Installed atk-1.9.0 > * Installed pango-1.8.2 > * Installed gtk-2.6.10 Om uses Gtkmm. It's only direct dependency related to all that stuff is Gtkmm (and libglademm). Upgrade those :) -DR- From jaromil at dyne.org Fri Jul 7 07:04:01 2006 From: jaromil at dyne.org (jaromil) Date: Fri Jul 7 07:07:03 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <44AC0D80.7050908@mytum.de> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> Message-ID: <20060707110401.GA17013@dyne.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, On Wed, Jul 05, 2006 at 09:05:36PM +0200, Niklas Kl?gel wrote: > wow, thanks! I am going to look into the source of the projects the > next days, currently pnpd triggers most of my attention. indeed, an interesting list! are there any plans to make pnpd compatible with pd patches? that would be reeeeally good IMHO. at least *some* layer of compatibility that could support documentation and examples. ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFErj+he2QxhLU0C14RAjHGAJ95X0UN8kghOJH0mcj2Lhim+6vUMwCg2W9p RdN2+Ha10n9PqPAY8k1z3UE= =ZkLN -----END PGP SIGNATURE----- From radarsat1 at gmail.com Fri Jul 7 10:24:23 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Fri Jul 7 10:24:30 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <20060707110401.GA17013@dyne.org> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> <20060707110401.GA17013@dyne.org> Message-ID: <9b3e2dc20607070724y7d9d0bb7u9337e3878982f0a9@mail.gmail.com> I also hadn't heard of pnpd... Sounds really interesting. I only took a few minutes to try it, I downloaded the source, but I think the version of SCons in my Ubuntu (Dapper) system wasn't new enough to work with the build script... In any case I played around but couldn't get it to compile. Steve On 7/7/06, jaromil wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > hi, > > On Wed, Jul 05, 2006 at 09:05:36PM +0200, Niklas Kl?gel wrote: > > wow, thanks! I am going to look into the source of the projects the > > next days, currently pnpd triggers most of my attention. > > indeed, an interesting list! > > are there any plans to make pnpd compatible with pd patches? > that would be reeeeally good IMHO. at least *some* layer of > compatibility that could support documentation and examples. > > ciao > > - -- > jaromil, dyne.org rasta coder, http://rastasoft.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQFErj+he2QxhLU0C14RAjHGAJ95X0UN8kghOJH0mcj2Lhim+6vUMwCg2W9p > RdN2+Ha10n9PqPAY8k1z3UE= > =ZkLN > -----END PGP SIGNATURE----- > From James at superbug.co.uk Sat Jul 8 08:34:44 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Jul 8 08:34:51 2006 Subject: [linux-audio-dev] Converting a 24bit sample to 16bit Message-ID: <44AFA664.8080608@superbug.co.uk> Hi, Is there a standard way of converting a 24bit sample to 16bit? I ask because I think that in different scenarios, one would want a different result. 1) scale a 24bit value to a 16bit by simple multiplication by a fraction. 2) bit shift the 24bit value, so that the "most useful 16bits" are returned to the user. The problem here is what are the "most useful 16bits"? I have one application where just using the lower 16bits of the 24bit value is ideal, due to extremely low input signals. Option (1) looses information due to compression of the signal. Option (2) is more likely to loose information through clipping. James From paul at linuxaudiosystems.com Sat Jul 8 08:44:46 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Jul 8 08:44:07 2006 Subject: [linux-audio-dev] Converting a 24bit sample to 16bit In-Reply-To: <44AFA664.8080608@superbug.co.uk> References: <44AFA664.8080608@superbug.co.uk> Message-ID: <1152362686.30718.42.camel@localhost.localdomain> On Sat, 2006-07-08 at 13:34 +0100, James Courtier-Dutton wrote: > Hi, > > Is there a standard way of converting a 24bit sample to 16bit? > I ask because I think that in different scenarios, one would want a > different result. > 1) scale a 24bit value to a 16bit by simple multiplication by a fraction. > 2) bit shift the 24bit value, so that the "most useful 16bits" are > returned to the user. The problem here is what are the "most useful > 16bits"? I have one application where just using the lower 16bits of the > 24bit value is ideal, due to extremely low input signals. > > Option (1) looses information due to compression of the signal. > Option (2) is more likely to loose information through clipping. google for "dither" From idragosani at gmail.com Sat Jul 8 08:51:34 2006 From: idragosani at gmail.com (Brett W. McCoy) Date: Sat Jul 8 08:51:43 2006 Subject: [linux-audio-dev] Converting a 24bit sample to 16bit In-Reply-To: <44AFA664.8080608@superbug.co.uk> References: <44AFA664.8080608@superbug.co.uk> Message-ID: <18b65aac0607080551m2346a52foe520e51aa4dcd9bf@mail.gmail.com> On 7/8/06, James Courtier-Dutton wrote: > Is there a standard way of converting a 24bit sample to 16bit? > I ask because I think that in different scenarios, one would want a > different result. > 1) scale a 24bit value to a 16bit by simple multiplication by a fraction. > 2) bit shift the 24bit value, so that the "most useful 16bits" are > returned to the user. The problem here is what are the "most useful > 16bits"? I have one application where just using the lower 16bits of the > 24bit value is ideal, due to extremely low input signals. Isn't this what dithering algorithms do for you? -- Brett McCoy: Programmer by Day, Guitarist by Night http://www.alhazred.com http://www.cassandrasyndrome.com http://www.revelmoon.com From fons.adriaensen at skynet.be Sat Jul 8 09:26:52 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sat Jul 8 09:26:24 2006 Subject: [linux-audio-dev] Converting a 24bit sample to 16bit In-Reply-To: <44AFA664.8080608@superbug.co.uk> References: <44AFA664.8080608@superbug.co.uk> Message-ID: <20060708132652.GA5951@linux-1.site> On Sat, Jul 08, 2006 at 01:34:44PM +0100, James Courtier-Dutton wrote: > Is there a standard way of converting a 24bit sample to 16bit? > I ask because I think that in different scenarios, one would want a > different result. > 1) scale a 24bit value to a 16bit by simple multiplication by a fraction. > 2) bit shift the 24bit value, so that the "most useful 16bits" are > returned to the user. The problem here is what are the "most useful > 16bits"? Bit shifting is just multiplication by a power of 2, so it's not essentially different from general multiplication. Normal practice would be to dither the 24 bit signal, then take the upper sixteen bits. > I have one application where just using the lower 16bits of the > 24bit value is ideal, due to extremely low input signals. That's really no good reason to divert from the normal practice. It probably means that your analog input signal is way too low for the input you are using, i.e. a mic connected to a line input. The solution here is to preamp it to a normal level before conversion, otherwise you're just amplifying the noise + hum + interference of your sound card. -- FA Follie! Follie! Delirio vano e' questo! From kouhia at nic.funet.fi Sat Jul 8 12:02:18 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sat Jul 8 12:02:28 2006 Subject: [linux-audio-dev] Re: LinuxSampler license Message-ID: In gimp list, I mentioned that I don't want my software to be used in Windows. That would encourage people to install Linux. My plan was to use GPL + Windows exclusion. I was very clearly informed that it would not work. Then why similar works for Linuxsampler? BTW, I'm still puzzled on what kind of license I should use. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From rlrevell at joe-job.com Sat Jul 8 12:07:08 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Jul 8 12:06:28 2006 Subject: [linux-audio-dev] Re: LinuxSampler license In-Reply-To: References: Message-ID: <1152374830.4736.172.camel@mindpipe> On Sat, 2006-07-08 at 19:02 +0300, Juhana Sadeharju wrote: > In gimp list, I mentioned that I don't want my software to be > used in Windows. That would encourage people to install Linux. > My plan was to use GPL + Windows exclusion. I was very clearly > informed that it would not work. > > Then why similar works for Linuxsampler? > It doesn't work. That's the whole point of this thread. Lee From TimBlechmann at gmx.net Sat Jul 8 05:01:52 2006 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Sat Jul 8 13:01:56 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <20060707110401.GA17013@dyne.org> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> <20060707110401.GA17013@dyne.org> Message-ID: <1152349312.9729.15.camel@localhost> hi all, > On Wed, Jul 05, 2006 at 09:05:36PM +0200, Niklas Kl?gel wrote: > > wow, thanks! I am going to look into the source of the projects the > > next days, currently pnpd triggers most of my attention. thanks ... > are there any plans to make pnpd compatible with pd patches? > that would be reeeeally good IMHO. at least *some* layer of > compatibility that could support documentation and examples. well, pd and pnpd won't be completely compatible, the syntax will be very similar, although some aspects are handled differently... but in any case, i'll write a pd-to-pnpd patch converter, that will handle most of the differences, but not all ... however i must say, pnpd is in a very early stage of development, it contains only a handful of objects and is missing a usable user interface ... christian klippel's karma will become a qt gui client, but currently they are not able to communicate ... i'll create a mailinglist about the pnpd project in the next few days, if some people are interested to subscribe, please drop me a line ... cheers ... tim -- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060708/bdba0bf3/attachment.bin From TimBlechmann at gmx.net Sat Jul 8 05:06:15 2006 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Sat Jul 8 13:02:13 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <9b3e2dc20607070724y7d9d0bb7u9337e3878982f0a9@mail.gmail.com> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> <20060707110401.GA17013@dyne.org> <9b3e2dc20607070724y7d9d0bb7u9337e3878982f0a9@mail.gmail.com> Message-ID: <1152349575.9729.21.camel@localhost> > I only took a few minutes to try it, I downloaded the source, but I > think the version of SCons in my Ubuntu (Dapper) system wasn't new > enough to work with the build script... > In any case I played around but couldn't get it to compile. pnpd requires a pretty recent version of scons to build ... however, even if you compile it, don't expect too much ... it will only play a test sine wave :) tim -- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk I had nothing to offer anybody except my own confusion Jack Kerouac -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060708/f504103a/attachment.bin From drobilla at connect.carleton.ca Sat Jul 8 13:55:52 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 8 13:56:03 2006 Subject: [linux-audio-dev] Re: LinuxSampler license In-Reply-To: References: Message-ID: <1152381352.32108.6.camel@localhost.localdomain> On Sat, 2006-07-08 at 19:02 +0300, Juhana Sadeharju wrote: > In gimp list, I mentioned that I don't want my software to be > used in Windows. That would encourage people to install Linux. > My plan was to use GPL + Windows exclusion. I was very clearly > informed that it would not work. > > Then why similar works for Linuxsampler? > > BTW, I'm still puzzled on what kind of license I should use. I don't wish for people to use my software in Windows either, but I persnally don't think that is an acceptable license restriction (and definitely would make your program neither Free Software or Open Source). The point of Free/Open Source software is the user's right to use the program as they wish, and (unfortunately?) that includes running it on whatever OS they please. In practise, unless your software is inherently portable to Windows (eg Java etc) unless you actually do a port normal users aren't going to end up using it anyway. A copyright license doesn't really apply to this sort of situation anyway, you'd have to create a heavy-handed MS-style evil EULA that tells people what they are allowed to do with software. Noble intentions, but isn't that the kind of thing we're trying to /prevent/? -DR- From phuocnh at ssp.com.vn Sun Jul 9 01:06:59 2006 From: phuocnh at ssp.com.vn (Huu Phuoc) Date: Sun Jul 9 01:02:10 2006 Subject: [linux-audio-dev] Set rate return zero Message-ID: <44B08EF3.80208@ssp.com.vn> Hi everybody! I am a newbie to alsa programming. I am trying to follow the article which locates at http://www.suse.de/~mana/alsa090_howto.html to develop a playback program. My code here: snd_pcm_t*pcm_handle; unsigned int rate = 8000; // Sample rate returned by // snd_pcm_hw_params_set_rate_near int exact_rate; // exact_rate == rate ----> dir =0 //exact_rate < rate ----> dir =-1 //exact_rate > rate ----> dir =1 int dir = 0; // Number of periods int periods = 2; snd_pcm_stream_t stream = SND_PCM_STREAM_PLAYBACK; // This structure contains information about the hardware //and can be used to specify the configuration to be used for the PCM stream. snd_pcm_hw_params_t *hwparams; // Name of the PCM device, like plughw:0,0 //The first number is the number of the soundcard, //the second number is the number of the device. char *pcm_name; // Init pcm_name. Of course, later you //will make this configurable ;-) pcm_name = strdup("plughw:0,0"); printf("Device name:%s\n",pcm_name); //Allocate the snd_pcm_hw_params_t structure on the stack. snd_pcm_hw_params_alloca(&hwparams); // Open PCM. The last parameter of this function is the mode. // If this is set to 0, the standard mode is used. Possible // other values are SND_PCM_NONBLOCK and SND_PCM_ASYNC. // If SND_PCM_NONBLOCK is used, read / write access to the // PCM device will return immediately. If SND_PCM_ASYNC is // specified, SIGIO will be emitted whenever a period has //been completely processed by the soundcard. if (snd_pcm_open(&pcm_handle, pcm_name, stream, 0) < 0){//SND_PCM_NONBLOCK fprintf(stderr, "Error opening PCM device %s\n", pcm_name); return; } // Init hwparams with full configuration space if (snd_pcm_hw_params_any(pcm_handle, hwparams) < 0) { fprintf(stderr, "Can not configure this PCM device.\n"); return; } // Set access type. This can be either SND_PCM_ACCESS_RW_INTERLEAVED or // SND_PCM_ACCESS_RW_NONINTERLEAVED.There are also access types for // MMAPed access, but this is beyond the scope of this introduction. if (snd_pcm_hw_params_set_access(pcm_handle, hwparams, SND_PCM_ACCESS_RW_INTERLEAVED) < 0) { fprintf(stderr, "Error setting access.\n"); return; } //Set sample format if (snd_pcm_hw_params_set_format(pcm_handle, hwparams, SND_PCM_FORMAT_S16_LE) < 0) { fprintf(stderr, "Error setting format.\n"); return; } // Set sample rate. If the exact rate is not supported by the hardware, use nearest possible rate. exact_rate = snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, &rate, &dir); if (exact_rate < 0) { fprintf(stderr, "Error setting rate.\n"); return; } if (rate != exact_rate) { fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n=> Using %d Hz instead.\n", rate, exact_rate); } // Set number of channels if (snd_pcm_hw_params_set_channels(pcm_handle, hwparams, 2) < 0) { fprintf(stderr, "Error setting channels.\n"); return; } // Set number of periods. Periods used to be called fragments. if (snd_pcm_hw_params_set_periods(pcm_handle, hwparams, periods, 0) < 0) { fprintf(stderr, "Error setting periods.\n"); return; } // Set buffer size (in frames). The resulting latency is given by // latency = periodsize * periods / (rate * bytes_per_frame) snd_pcm_uframes_t buffersize = ( snd_pcm_uframes_t )( number_of_frames * periods ); if (snd_pcm_hw_params_set_buffer_size_near(pcm_handle, hwparams, &buffersize) < 0){ fprintf(stderr, "Error setting buffersize.\n"); return; } printf("Buffer size asked for %d, set %d \n",buffersize,exact_rate); // Apply HW parameter settings to // PCM device and prepare device if (snd_pcm_hw_params(pcm_handle, hwparams) < 0) { fprintf(stderr, "Error setting HW params.\n"); return; } snd_pcm_prepare(pcm_handle); Unfortunately, exact_rate is zero.The following lines were printed out: The rate 8000 Hz is not supported by your hardware. => Using 0 Hz instead. If exact_rate > 0 is OK but it is zero. I don't know how to solve the problem. Please help me. Thanks! Phuoc Nguyen From thockin at hockin.org Sun Jul 9 03:06:44 2006 From: thockin at hockin.org (thockin@hockin.org) Date: Sun Jul 9 03:06:59 2006 Subject: [linux-audio-dev] Converting a 24bit sample to 16bit In-Reply-To: <44AFA664.8080608@superbug.co.uk> References: <44AFA664.8080608@superbug.co.uk> Message-ID: <20060709070644.GA19212@hockin.org> On Sat, Jul 08, 2006 at 01:34:44PM +0100, James Courtier-Dutton wrote: > Is there a standard way of converting a 24bit sample to 16bit? > I ask because I think that in different scenarios, one would want a > different result. As others have said - dither and drop the low 8 bits. But... > returned to the user. The problem here is what are the "most useful > 16bits"? I have one application where just using the lower 16bits of the > 24bit value is ideal, due to extremely low input signals. Normalize the 24 bit sample first? From jens.andreasen at chello.se Sun Jul 9 08:03:50 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Jul 9 08:04:03 2006 Subject: [linux-audio-dev] Set rate return zero In-Reply-To: <44B08EF3.80208@ssp.com.vn> References: <44B08EF3.80208@ssp.com.vn> Message-ID: <1152446630.9274.515.camel@c80-216-124-251.cm-upc.chello.se> On Sun, 2006-07-09 at 12:06 +0700, Huu Phuoc wrote: > Hi everybody! > I am a newbie to alsa programming. > I am trying to follow the article which locates at > http://www.suse.de/~mana/alsa090_howto.html to develop a playback program. > My code here: > snd_pcm_t*pcm_handle; > unsigned int rate = 8000; ^^^^^^ [snip] > snd_pcm_prepare(pcm_handle); > Unfortunately, exact_rate is zero.The following lines were printed out: > The rate 8000 Hz is not supported by your hardware. > => Using 0 Hz instead. > If exact_rate > 0 is OK but it is zero. > I don't know how to solve the problem. > Please help me. Try to replace "rate = 8000" with something that *is* supported by your hardware. 48000 could be a good choice. > Thanks! > Phuoc Nguyen -- From mista.tapas at gmx.net Sun Jul 9 11:20:57 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Sun Jul 9 11:21:08 2006 Subject: [linux-audio-dev] Set rate return zero In-Reply-To: <1152446630.9274.515.camel@c80-216-124-251.cm-upc.chello.se> References: <44B08EF3.80208@ssp.com.vn> <1152446630.9274.515.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060709172057.3c1e82d8@mango.fruits> On Sun, 09 Jul 2006 14:03:50 +0200 Jens M Andreasen wrote: > On Sun, 2006-07-09 at 12:06 +0700, Huu Phuoc wrote: > > Hi everybody! > > I am a newbie to alsa programming. > > I am trying to follow the article which locates at > > http://www.suse.de/~mana/alsa090_howto.html to develop a playback program. > > My code here: > > > snd_pcm_t*pcm_handle; > > unsigned int rate = 8000; > ^^^^^^ > [snip] > > > snd_pcm_prepare(pcm_handle); > > Unfortunately, exact_rate is zero.The following lines were printed out: > > > The rate 8000 Hz is not supported by your hardware. > > => Using 0 Hz instead. > > > If exact_rate > 0 is OK but it is zero. > > I don't know how to solve the problem. > > Please help me. > > Try to replace "rate = 8000" with something that *is* supported by your > hardware. 48000 could be a good choice. He uses "plughw:0" as pcm dcevice, no? THis should take care of converting the samplerte regardless of what his hw supports. Flo -- Palimm Palimm! http://tapas.affenbande.org From phuocnh at ssp.com.vn Sun Jul 9 11:49:27 2006 From: phuocnh at ssp.com.vn (Phuoc H. Nguyen) Date: Sun Jul 9 11:44:25 2006 Subject: [linux-audio-dev] Re: Set rate return zero In-Reply-To: <20060709172057.3c1e82d8@mango.fruits> References: <44B08EF3.80208@ssp.com.vn> <1152446630.9274.515.camel@c80-216-124-251.cm-upc.chello.se> <20060709172057.3c1e82d8@mango.fruits> Message-ID: <44B12587.2090105@ssp.com.vn> Thank you, Schmidt! Now, I have just solved my problem. exact_rate is still zero but the sound is OK. Phuoc Nguyen Florian Paul Schmidt wrote: > > He uses "plughw:0" as pcm dcevice, no? THis should take care of > converting the samplerte regardless of what his hw supports. > > Flo > > > From james at dis-dot-dat.net Sun Jul 9 20:06:26 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Sun Jul 9 20:06:33 2006 Subject: [linux-audio-dev] A bit of an [ANN] :) Message-ID: <20060710000626.GJ21695@fitz.Belkin> Howdy peeps. Not really much of a release, so not much fanfare, but in the interests of sharing effort I give you... Powernap! http://dis-dot-dat.net/?item=code/powernap/ If, like me, you need to drive an app from a Python interface, powernap can help. It's a small extension that switches to the real-time scheduler and provides two handy sleep-like functions: nap() naps for a given number of milliseconds, timed with the RTC rnap() is a "rolling nap" that tries to make the time between calls the given number of milliseconds. A padding nap, if you will. It works for me and it might come in handy for someone else. James From radarsat1 at gmail.com Sun Jul 9 22:44:17 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Sun Jul 9 22:44:30 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <1152349575.9729.21.camel@localhost> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> <20060707110401.GA17013@dyne.org> <9b3e2dc20607070724y7d9d0bb7u9337e3878982f0a9@mail.gmail.com> <1152349575.9729.21.camel@localhost> Message-ID: <9b3e2dc20607091944m75bb0cddh36a4897b818d8bf9@mail.gmail.com> ah, cool. just curious, what is your dev environment then? (distro, etc.) i might be interested in contributing some code eventually... (partly cause i was once considering re-writing pd from scratch as well, but decided it was too big a project for the amount of time i have right now..) steve On 7/8/06, Tim Blechmann wrote: > > I only took a few minutes to try it, I downloaded the source, but I > > think the version of SCons in my Ubuntu (Dapper) system wasn't new > > enough to work with the build script... > > In any case I played around but couldn't get it to compile. > > pnpd requires a pretty recent version of scons to build ... however, > even if you compile it, don't expect too much ... it will only play a > test sine wave :) > > tim > > -- > tim@klingt.org ICQ: 96771783 > http://www.mokabar.tk > > I had nothing to offer anybody except my own confusion > Jack Kerouac > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.4 (GNU/Linux) > > iD8DBQBEr3WHNDZZF/Yk3sURAqxyAJ4/JTiV9cgUq2omSeGRtWzkyVuukgCgioSz > 9K620s2SJD1tdy/O2tPCpbo= > =Da8f > -----END PGP SIGNATURE----- > > > From TimBlechmann at gmx.net Mon Jul 10 07:14:05 2006 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Mon Jul 10 07:11:27 2006 Subject: [linux-audio-dev] modular sequencing environment/synth // any projects to dig in? In-Reply-To: <9b3e2dc20607091944m75bb0cddh36a4897b818d8bf9@mail.gmail.com> References: <44ABF17E.5070606@mytum.de> <20060705183617.GB3299@replic.net> <20060705184409.GC3299@replic.net> <44AC0D80.7050908@mytum.de> <20060707110401.GA17013@dyne.org> <9b3e2dc20607070724y7d9d0bb7u9337e3878982f0a9@mail.gmail.com> <1152349575.9729.21.camel@localhost> <9b3e2dc20607091944m75bb0cddh36a4897b818d8bf9@mail.gmail.com> Message-ID: <1152530045.8796.10.camel@localhost> hi steve, On Sun, 2006-07-09 at 22:44 -0400, Stephen Sinclair wrote: > ah, cool. > just curious, what is your dev environment then? > (distro, etc.) i'm currently working on gentoo/gcc-4.1.1, but every recent gcc (i.e. >= 3.4 should work). although i'm developing on linux, i'm trying to keep it cross-platform and also support osx/win32... > i might be interested in contributing some code eventually... > (partly cause i was once considering re-writing pd from scratch as > well, but decided it was too big a project for the amount of time i > have right now..) i have created a mailing list to cover the development ... feel free to subscribe at https://klingt.org/cgi-bin/mailman/listinfo/pnpd-dev cheers ... tim -- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk Just what the hell is the experimental tradition? Morton Feldman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060710/88eef241/attachment.bin From drobilla at connect.carleton.ca Mon Jul 10 12:39:58 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jul 10 12:40:04 2006 Subject: [linux-audio-dev] A bit of an [ANN] :) Message-ID: <6454675.1152549598578.JavaMail.drobilla@connect.carleton.ca> james@dis-dot-dat.net wrote: >Howdy peeps. > >Not really much of a release, so not much fanfare, but in the >interests of sharing effort I give you... > >Powernap! > >http://dis-dot-dat.net/?item=code/powernap/ > >If, like me, you need to drive an app from a Python interface, >powernap can help. It's a small extension that switches to the >real-time scheduler and provides two handy sleep-like functions: > >nap() naps for a given number of milliseconds, timed with the RTC > >rnap() is a "rolling nap" that tries to make the time between calls >the given number of milliseconds. A padding nap, if you will. > >It works for me and it might come in handy for someone else. Nice, this will definitely come in handy for me. Have you done any benchmarking on what kind of timing precision you can get? -DR- From james at dis-dot-dat.net Mon Jul 10 17:10:56 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Mon Jul 10 17:11:07 2006 Subject: [linux-audio-dev] A bit of an [ANN] :) In-Reply-To: <6454675.1152549598578.JavaMail.drobilla@connect.carleton.ca> References: <6454675.1152549598578.JavaMail.drobilla@connect.carleton.ca> Message-ID: <20060710211056.GN21695@fitz.Belkin> On Mon, 10 Jul, 2006 at 12:39PM -0400, Dave Robillard spake thus: > > > > james@dis-dot-dat.net wrote: > > > >Howdy peeps. > > > >Not really much of a release, so not much fanfare, but in the > >interests of sharing effort I give you... > > > >Powernap! > > > >http://dis-dot-dat.net/?item=code/powernap/ > > > >If, like me, you need to drive an app from a Python interface, > >powernap can help. It's a small extension that switches to the > >real-time scheduler and provides two handy sleep-like functions: > > > >nap() naps for a given number of milliseconds, timed with the RTC > > > >rnap() is a "rolling nap" that tries to make the time between calls > >the given number of milliseconds. A padding nap, if you will. > > > >It works for me and it might come in handy for someone else. > > Nice, this will definitely come in handy for me. Good! I'm trying to see where I'm writing things that others can make use of and make them fairly simple to reuse. > Have you done any benchmarking on what kind of timing precision you can > get? Nothing particularly concrete. On my amd64 3700 sandiego, with other apps running (normal desktop kinda stuff), aiming for a time between sleeps of 310ms using rnap, I get a minimum gap of 308.34 and a maximum of 312.48, so the range is about 5ms. Standard deviation is 0.67, though and the average is 310.4. Which is quite good, from Python, I think. I think there might be a way for it to automatically compensate over time for tending to be a little over, but 0.4ms probably isn't worth it. James > -DR- > From torbenh at gmx.de Tue Jul 11 06:10:43 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Jul 11 06:11:50 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630144441.GJ20075@storm.local.network> References: <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <20060630142503.GB13275@teasel.arb.net> <20060630144441.GJ20075@storm.local.network> Message-ID: <20060711101043.GA8043@mobilat> On Fri, Jun 30, 2006 at 10:44:41AM -0400, Forest Bond wrote: ok... after some timeout, i am in full effect again. fst is already able to load/save chunks. i dont have a full version of kontakt, so i cant verify whether load/save works. i guess you guys already know, that you HAVE to use lash to restore any vst plugin states. please report back, whether it works with kontakt. http://galan.sf.net/fst-1.9.tar.gz > > > In any case, Linux Sampler and Kontakt are > > > different sorts of samplers at this point. Linux Sampler is more in the spirit > > > of Gigasampler, and Kontakt is more like an emulation of a hardware sampler (but > > > vastly more flexible). > > > > The key words there are "at this point." As noted, the *long-term* > > potential of Linux Sampler is probably still much greater than Kontakt-in-wine. > > Agreed. Maybe time is best spent improving linux sampler. Then again, good VST > has benefits, although I do see how it may hurt the long term goals of free > software. I'm just not sure if the best way to help free software is to limit > it's ability to integrate with proprietary software. > > > > > > > Noted. However, I remain unconvinced that Linux Sampler is intended to be a > > > drop-in replacement for something like Kontakt. > > > > I don't think it's intended to be a drop-in replacement for Kontakt; I > > think it's just intended to be cool. > > I can appreciate that. > > -Forest -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From asbjs at stud.ntnu.no Tue Jul 11 07:54:09 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Tue Jul 11 07:54:15 2006 Subject: [linux-audio-dev] More pictures from LAC2006 Message-ID: <20060711115409.GB28052@stud.ntnu.no> A bit late, but maybe still of interest. A number of pictures from LAC2006 may be downloaded from . (The file is around 9MB.) * netjack workshop * Linux sound night * various With thanks for and interesting conference and nice company there! Asbj?rn S?b? From ce at christeck.de Tue Jul 11 12:55:15 2006 From: ce at christeck.de (Christoph Eckert) Date: Tue Jul 11 12:56:31 2006 Subject: [linux-audio-dev] More pictures from LAC2006 In-Reply-To: <20060711115409.GB28052@stud.ntnu.no> References: <20060711115409.GB28052@stud.ntnu.no> Message-ID: <200607111855.15314.ce@christeck.de> > www.q2s.ntnu.no/~asbjs/pictures_lac2006_asbjorn-sabo.tar thx a bunch. What about a post on LAU? Cheers, ce From drobilla at connect.carleton.ca Tue Jul 11 17:06:03 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 11 17:06:26 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060604232101.GA29257@space.twc.de> References: <20060604232101.GA29257@space.twc.de> Message-ID: <1152651965.25882.16.camel@DaveLap> On Mon, 2006-06-05 at 01:21 +0200, Stefan Westerfeld wrote: > Hi! > > I am trying to notify a high priority (nice -20 or nice -19) thread from > a realtime thread (from a jack callback to be precise). Of course I want > the realtime thread to not block, but I want the high priority thread to > react as soon as possible. For the first implementation, I used a > condition, and pthread_cond_signal. But as I can't aquire a mutex within > the realtime thread, at least not always (at most with trylock()), this > results in racy code. > > Also, it doesn't integrate well with poll(), which the high priority > process should be able to use. So basically I want to switch to a pipe > write() instead of pthread_cond_signal. I seem to be alone on this, but I still say semaphores are the best for this - sem_post is async signal safe. It might not be pedantically "realtime safe" (depending what the Linux guys have done with futexes I guess) but it's certainly far better than a mutex/cond pair (and I would guess better than writing to a pipe as well). A mutex obviously isn't async signal safe, and I doubt writing to a pipe is either. It's also handy that a semaphore is a counter, so you can easily gracefully handle the case where the realtime thread is going a lot faster than the consumer, or the consumer gets hung up for a little bit, etc. Semaphores seem about perfect for this to me.. am I missing something? Why doesn't anyone ever recommend them? -DR- From paul at linuxaudiosystems.com Tue Jul 11 17:10:27 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jul 11 17:10:01 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152651965.25882.16.camel@DaveLap> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> Message-ID: <1152652227.30718.139.camel@localhost.localdomain> On Tue, 2006-07-11 at 17:06 -0400, Dave Robillard wrote: > Semaphores seem about perfect for this to me.. am I missing something? > Why doesn't anyone ever recommend them? i think mostly because in 2000-2001, they were very slow. From stefan at space.twc.de Tue Jul 11 18:26:14 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Tue Jul 11 18:22:19 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152651965.25882.16.camel@DaveLap> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> Message-ID: <20060711222614.GA12744@space.twc.de> Hi! On Tue, Jul 11, 2006 at 05:06:03PM -0400, Dave Robillard wrote: > On Mon, 2006-06-05 at 01:21 +0200, Stefan Westerfeld wrote: > > I am trying to notify a high priority (nice -20 or nice -19) thread from > > a realtime thread (from a jack callback to be precise). Of course I want > > the realtime thread to not block, but I want the high priority thread to > > react as soon as possible. For the first implementation, I used a > > condition, and pthread_cond_signal. But as I can't aquire a mutex within > > the realtime thread, at least not always (at most with trylock()), this > > results in racy code. > > > > Also, it doesn't integrate well with poll(), which the high priority > > process should be able to use. So basically I want to switch to a pipe > > write() instead of pthread_cond_signal. > > I seem to be alone on this, but I still say semaphores are the best for > this - sem_post is async signal safe. It might not be pedantically > "realtime safe" (depending what the Linux guys have done with futexes I > guess) Well after Lee's reply, and looking at the code again, I think I think the Linux guys did everything right, and semaphores should be realtime safe. > but it's certainly far better than a mutex/cond pair (and I would > guess better than writing to a pipe as well). A mutex obviously isn't > async signal safe, and I doubt writing to a pipe is either. > > It's also handy that a semaphore is a counter, so you can easily > gracefully handle the case where the realtime thread is going a lot > faster than the consumer, or the consumer gets hung up for a little bit, > etc. > > Semaphores seem about perfect for this to me.. am I missing something? Since we've been comparing different methods here, I thought I might as well write a benchmark, to look at the performance, too. I wrote a little test which repeatedly switches between two threads, which wakeup eachother using a pipe, cond or semaphore. On an AMD64 3400+ (2200 MHz) running a 2.6.16.16 kernel with preemption enabled, the timings for 1000000 iterations (each thread runs a brief period of time 1000000 times) are - about 5.7 seconds when using a wakeup pipe and poll - about 5.7 seconds when using a condition with mutex - about 2.0 seconds when using a semaphore So: if what you're doing doesn't restrict you in any way, then semaphores are probably the thing to use. If you need to wait for multiple things simultaneously (like audio device fd and another thread), then you can do it with pipes and poll, but not with semaphores. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From drobilla at connect.carleton.ca Tue Jul 11 19:43:09 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 11 19:43:33 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060711222614.GA12744@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> Message-ID: <1152661389.1071.9.camel@DaveLap> On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote: > > Semaphores seem about perfect for this to me.. am I missing something? > > Since we've been comparing different methods here, I thought I might as > well write a benchmark, to look at the performance, too. I wrote a > little test which repeatedly switches between two threads, which wakeup > eachother using a pipe, cond or semaphore. > > On an AMD64 3400+ (2200 MHz) running a 2.6.16.16 kernel with preemption > enabled, the timings for 1000000 iterations (each thread runs a brief > period of time 1000000 times) are > > - about 5.7 seconds when using a wakeup pipe and poll > - about 5.7 seconds when using a condition with mutex > - about 2.0 seconds when using a semaphore > > So: if what you're doing doesn't restrict you in any way, then > semaphores are probably the thing to use. > > If you need to wait for multiple things simultaneously (like audio > device fd and another thread), then you can do it with pipes and poll, > but not with semaphores. Nice. I win! :) I'd noticed a set of the pants improvement (increased event processing throughput) when I switch to semaphores, but never ran a real benchmark. Good point on waiting for multiple things though, poll is a lot more flexible than semaphores (though I still say writing to a pipe in a realtime thread is pretty sketchy...). Pipes let you communicate between processes though - I havn't tried the fancier POSIX interprocess stuff yet. -DR- From kjetil at ccrma.stanford.edu Tue Jul 11 21:11:57 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Tue Jul 11 21:12:19 2006 Subject: [linux-audio-dev] [ANN] jack_capture V0.3.1, das_watchdog V0.2.2 and Mammut V0.22 Message-ID: http://ccrma.stanford.edu/~kjetil/src/ jack_capture ************************************************************************* jack_capture is a small program to capture whatever sound is going out to your speakers into a file without having to patch jack connections, fiddle around with fileformats, or set options on the argument line. This is the program I always wanted to have for jack, but no one made. So here it is. Changes 0.2.4 -> 0.3.1: ----------------------- *Reduced CPU usage a lot because of better disk handling. (25% -> 1%) *Make sure the rest of the recorded file is not garbage in case of an overrun. *Added the port argument, which can be specified many times and accepts both input and output port names (including regexp expressions). This makes jack_capture to completely replace jackrec. *Rewrote buffer handling. Silence is now inserted when underruns occure. Previously, the file became shorter than the recording in case of underrun. It can still happen though, but much more seldom, and a warning about that will be printed to the terminal. *Last rests of jackrec code has been rewritten. Well, all the code with substance, at least. *Nicified code a lot. *More efficient way of handling overruns. *Fixed really stupid compilation error. Thanks to Dragan Noveski for spotting it. das_watchdog ************************************************************************* Whenever a program locks up the machine, das_watchdog will temporarily sets all realtime process to non-realtime for 8 seconds. You will get an xmessage window up on the screen whenever that happens. Changes 0.2.2->0.2.3 -------------------- *Fixed commandline arguments for increasetime, checktime and waittime. *Nicified source a bit Mammut ************************************************************************* Mammut will FFT your sound in one single gigantic analysis (no windows). These spectral data, where the development in time is incorporated in mysterious ways, may then be transformed by different algorithms prior to resynthesis. An interesting aspect of Mammut is its completely non-intuitive sound transformation approach. Changes 0.21->0.22 ------------------ *Added patch and instructions from Owen Green on how to make mammut compile on OSX. Thanks! (Sorry, I forgot to release this version for almost a year...) From forest at alittletooquiet.net Tue Jul 11 21:20:53 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Tue Jul 11 21:21:04 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060711101043.GA8043@mobilat> References: <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <20060630142503.GB13275@teasel.arb.net> <20060630144441.GJ20075@storm.local.network> <20060711101043.GA8043@mobilat> Message-ID: <20060712012053.GA18945@localdomain> > fst is already able to load/save chunks. It sure as heck is. > i dont have a full version of kontakt, so i cant verify whether > load/save works. Seems to work pretty well. I haven't tested it real thorougly, but everything looks to be in order. The 1.8 -> 1.9 diff is not large. Wish I knew my way around the VST stuff. Things were underway to create a new (read: kontakt-ish) interface for chionic. I would like to keep at that, I think, but kontakt is working quite well now. I guess I have to figure out what I have time for, exactly. Thanks for taking the time to implement this, Torbenh. thanks, Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060711/299d1af7/attachment.bin From wingo at pobox.com Wed Jul 12 04:20:40 2006 From: wingo at pobox.com (Andy Wingo) Date: Wed Jul 12 04:20:47 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060711222614.GA12744@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> Message-ID: <1152692440.8296.3.camel@localhost.localdomain> Hi Stefan, On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote: > I wrote a > little test which repeatedly switches between two threads, which wakeup > eachother using a pipe, cond or semaphore. Nice :) Can you upload it somewhere? Cheers, -- Andy Wingo http://wingolog.org/ From pcoccoli at gmail.com Wed Jul 12 08:11:59 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Jul 12 08:12:06 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060711222614.GA12744@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> Message-ID: <8d27a0610607120511m43aae96uecac121294cdfe3b@mail.gmail.com> On 7/11/06, Stefan Westerfeld wrote: > Since we've been comparing different methods here, I thought I might as > well write a benchmark, to look at the performance, too. I wrote a > little test which repeatedly switches between two threads, which wakeup > eachother using a pipe, cond or semaphore. > > On an AMD64 3400+ (2200 MHz) running a 2.6.16.16 kernel with preemption > enabled, the timings for 1000000 iterations (each thread runs a brief > period of time 1000000 times) are > > - about 5.7 seconds when using a wakeup pipe and poll > - about 5.7 seconds when using a condition with mutex > - about 2.0 seconds when using a semaphore > > So: if what you're doing doesn't restrict you in any way, then > semaphores are probably the thing to use. > > If you need to wait for multiple things simultaneously (like audio > device fd and another thread), then you can do it with pipes and poll, > but not with semaphores. > > Cu... Stefan > -- > Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan > What about POSIX real-time signals? I know mixing threads and signals is taboo, but I thought I'd throw it out there anyway. Using pselect then lets you wait atomically for events on file descriptors and/or signals. Not sure how well it works with threads, though...or if it's even implemented (though it is described in select(2)). From James at superbug.co.uk Wed Jul 12 09:26:11 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Wed Jul 12 09:26:20 2006 Subject: [linux-audio-dev] Creative EMU1212m Message-ID: <44B4F873.5030504@superbug.co.uk> Hi, Are there any people on this list who would be able to help test a Linux ALSA driver for the EMU1212m. I am now in a position to write a driver that works for this sound card. I currently have SPDIF output working, but other support will follow soon after that. I do not have an AudioDock or any ADAT equipment, so I would need particular help with testing that. Kind Regards James From jussi.laako at pp.inet.fi Wed Jul 12 13:54:14 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Wed Jul 12 13:54:21 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152661389.1071.9.camel@DaveLap> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> <1152661389.1071.9.camel@DaveLap> Message-ID: <44B53746.6070903@pp.inet.fi> Dave Robillard wrote: > realtime thread is pretty sketchy...). Pipes let you communicate > between processes though - I havn't tried the fancier POSIX interprocess > stuff yet. What do you mean by semaphore then, if not sem_*()? sem_post(3)/sem_wait(3) are defined in POSIX realtime extensions (librt in glibc). I would recommend _NOT_ to mix these semaphores (or shared memory, or message queues) with anything from SysV which is usually veeery far from being realtime safe, from implementation point of view. IF the implementation happens to be the same in Linux, doesn't mean that's the case in any other POSIX system. Of course you can share semaphores between processes because the semaphores reside within common namespace (see sem_open(3)). - Jussi P.S. There's also nice sem_overview(7) man page nowadays. From jaromil at dyne.org Wed Jul 12 17:43:37 2006 From: jaromil at dyne.org (jaromil) Date: Wed Jul 12 17:46:38 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152652227.30718.139.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <1152652227.30718.139.camel@localhost.localdomain> Message-ID: <20060712214337.GA19931@dyne.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jul 11, 2006 at 05:10:27PM -0400, Paul Davis wrote: > On Tue, 2006-07-11 at 17:06 -0400, Dave Robillard wrote: > > Semaphores seem about perfect for this to me.. am I missing something? > > Why doesn't anyone ever recommend them? > > i think mostly because in 2000-2001, they were very slow. IMHO they are still slow, especially when you port software to OSX then pthreads and semaphores are *very* slow (well, it depends how much and where you use them of course). my solution so far is assuming that boolean is atomical. all multi threaded handling i wrote is based on this assumption: i use it in pipe and linklist classes, but semaphores could also be there. i found no probems and good speed so far ... and life is boring without risks :)) ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEtW0Je2QxhLU0C14RAgoFAJ46wjWQ1TQcuisiWAGlNUe/r+4q0wCeKbhc 1LwvuKrz6u5FrljSDS6J4F0= =RTwn -----END PGP SIGNATURE----- From rlrevell at joe-job.com Wed Jul 12 17:56:00 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jul 12 17:56:03 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060712214337.GA19931@dyne.org> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <1152652227.30718.139.camel@localhost.localdomain> <20060712214337.GA19931@dyne.org> Message-ID: <1152741361.5145.7.camel@mindpipe> On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote: > my solution so far is assuming that boolean is atomical. > all multi threaded handling i wrote is based on this assumption: i use > it in pipe and linklist classes, but semaphores could also be there. > > i found no probems and good speed so far > ... and life is boring without risks :)) How does that help with IPC? I thought this thread was about a realtime safe IPC mechanism? Lee From jens.andreasen at chello.se Wed Jul 12 19:55:25 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Jul 12 19:55:35 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060712214337.GA19931@dyne.org> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <1152652227.30718.139.camel@localhost.localdomain> <20060712214337.GA19931@dyne.org> Message-ID: <1152748525.9274.548.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote: > > i think mostly because in 2000-2001, they were very slow. > > IMHO they are still slow, especially when you port software to OSX then > pthreads and semaphores are *very* slow (well, it depends how much and > where you use them of course). OSX? Although I can see your argument (of convenience), it has no beaeing to the implementation in linux. If you say that Darwin is lacking, then fix it or use Linux, no? > > my solution so far is assuming that boolean is atomical. > all multi threaded handling i wrote is based on this assumption: i use > it in pipe and linklist classes, but semaphores could also be there. > > i found no probems and good speed so far > ... and life is boring without risks :)) > ... and sooner or later we will find an update for multi-processors. :-D > ciao cheers! From stefan at space.twc.de Wed Jul 12 20:24:08 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Wed Jul 12 20:18:31 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152692440.8296.3.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> <1152692440.8296.3.camel@localhost.localdomain> Message-ID: <20060713002408.GA18994@space.twc.de> Hi! On Wed, Jul 12, 2006 at 10:20:40AM +0200, Andy Wingo wrote: > On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote: > > I wrote a > > little test which repeatedly switches between two threads, which wakeup > > eachother using a pipe, cond or semaphore. > > Nice :) Can you upload it somewhere? Yes, you can get it here: http://space.twc.de/~stefan/download/thread_switch_benchmark.tar.bz2 Originally I didn't write the code with the idea in mind that others may want to use it, without having beasts birnet library available. But I did some slightly hackish things to make it (hopefully) self-contained now. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From letz at grame.fr Thu Jul 13 05:15:58 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Thu Jul 13 05:18:15 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060713002408.GA18994@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> <1152692440.8296.3.camel@localhost.localdomain> <20060713002408.GA18994@space.twc.de> Message-ID: <76343122-491A-4540-B9AC-CD83792458B3@grame.fr> Le 13 juil. 06 ? 02:24, Stefan Westerfeld a ?crit : > Hi! > > On Wed, Jul 12, 2006 at 10:20:40AM +0200, Andy Wingo wrote: >> On Wed, 2006-07-12 at 00:26 +0200, Stefan Westerfeld wrote: >>> I wrote a >>> little test which repeatedly switches between two threads, which >>> wakeup >>> eachother using a pipe, cond or semaphore. >> >> Nice :) Can you upload it somewhere? > > Yes, you can get it here: > > http://space.twc.de/~stefan/download/thread_switch_benchmark.tar.bz2 > > Originally I didn't write the code with the idea in mind that others > may want to use it, without having beasts birnet library available. > But > I did some slightly hackish things to make it (hopefully) self- > contained > now. > > Cu... Stefan > -- There is code for real-time IPC in Jackdmp (http://www.grame.fr/ ~letz/jackdmp.html) - FIFO in JackFifo.cpp,h files - POSIX semaphore in JackPosixSemaphore.cpp,h files - Mach semaphore (OSX) in JackMachSemaphore.cpp,h files - Event (Windows) in JackWinEvent.cpp,h files Also code for timing bench in testSynchroClient.cpp, testSynchroServer.cpp and testSynchroServerClient.cpp Stephane From jaromil at dyne.org Thu Jul 13 07:37:11 2006 From: jaromil at dyne.org (jaromil) Date: Thu Jul 13 07:40:12 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152741361.5145.7.camel@mindpipe> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <1152652227.30718.139.camel@localhost.localdomain> <20060712214337.GA19931@dyne.org> <1152741361.5145.7.camel@mindpipe> Message-ID: <20060713113711.GA3942@dyne.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 12, 2006 at 05:56:00PM -0400, Lee Revell wrote: > On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote: > > my solution so far is assuming that boolean is atomical. > > all multi threaded handling i wrote is based on this assumption: i use > > it in pipe and linklist classes, but semaphores could also be there. > > > > i found no probems and good speed so far > > ... and life is boring without risks :)) > > How does that help with IPC? I thought this thread was about a realtime > safe IPC mechanism? the approach i'm using is multi-threading and shared memory: in critical loops messages are passed as booleans (but i keep #defines to change them into mutexes if necessary). in fact i'm a bit off topic since i don't use multiple processes; for that i can confirm that poll(2) is the most efficient and portable method i found. just my 2 pesetas :) ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEtjBne2QxhLU0C14RAi9gAJ4mEDl8MtS8MPjqNtyjt/6cm96HlwCcCAtm 8pyuZA70O2BtDPW8J0nVcRY= =mMJH -----END PGP SIGNATURE----- From jaromil at dyne.org Thu Jul 13 07:42:08 2006 From: jaromil at dyne.org (jaromil) Date: Thu Jul 13 07:45:12 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152748525.9274.548.camel@c80-216-124-251.cm-upc.chello.se> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <1152652227.30718.139.camel@localhost.localdomain> <20060712214337.GA19931@dyne.org> <1152748525.9274.548.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060713114208.GB3942@dyne.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 13, 2006 at 01:55:25AM +0200, Jens M Andreasen wrote: > On Wed, 2006-07-12 at 23:43 +0200, jaromil wrote: > > > > i think mostly because in 2000-2001, they were very slow. > > > > IMHO they are still slow, especially when you port software to OSX > > then pthreads and semaphores are *very* slow (well, it depends how > > much and where you use them of course). > > OSX? Although I can see your argument (of convenience), it has no > beaeing to the implementation in linux. If you say that Darwin is > lacking, then fix it or use Linux, no? i use Linux of course. i also dislike Darwin and would never spend time fixing it for Apple; but many (l)users are using OSX and is somehow interesting to port applications to it. > > my solution so far is assuming that boolean is atomical. all multi > > threaded handling i wrote is based on this assumption: i use it in > > pipe and linklist classes, but semaphores could also be there. > > > > i found no probems and good speed so far > > ... and life is boring without risks :)) > > > ... and sooner or later we will find an update for multi-processors. > :-D eheh, well, amazingly enough, i have no problems on SMP at all! :> ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEtjGQe2QxhLU0C14RAkOIAKDvVgo5yuxC+LOm6eDA3YARCfm8VACguAw8 cUF+BBn9f3Ls5Ui5owXrtrE= =pjM8 -----END PGP SIGNATURE----- From drobilla at connect.carleton.ca Thu Jul 13 12:13:06 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Jul 13 12:13:38 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <44B53746.6070903@pp.inet.fi> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> <1152661389.1071.9.camel@DaveLap> <44B53746.6070903@pp.inet.fi> Message-ID: <1152807187.4856.4.camel@DaveLap> On Wed, 2006-07-12 at 20:54 +0300, Jussi Laako wrote: > Dave Robillard wrote: > > realtime thread is pretty sketchy...). Pipes let you communicate > > between processes though - I havn't tried the fancier POSIX interprocess > > stuff yet. > > What do you mean by semaphore then, if not sem_*()? > sem_post(3)/sem_wait(3) are defined in POSIX realtime extensions (librt > in glibc). I would recommend _NOT_ to mix these semaphores (or shared > memory, or message queues) with anything from SysV which is usually > veeery far from being realtime safe, from implementation point of view. > IF the implementation happens to be the same in Linux, doesn't mean > that's the case in any other POSIX system. Sorry, I /was/ referring to sem_post/sem_wait/etc. I mean havn't tried any interprocess posix signalling stuff, like named semaphores or message queues. Benchmarking message queues against pipes would be interesting, maybe Jack could benefit if they're faster? -DR- From drobilla at connect.carleton.ca Thu Jul 13 12:32:17 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Jul 13 12:32:48 2006 Subject: [linux-audio-dev] crossplatform atomics In-Reply-To: <20060524171352.a188e881.mdeboer@iua.upf.es> References: <20060524171352.a188e881.mdeboer@iua.upf.es> Message-ID: <1152808337.4856.14.camel@DaveLap> On Wed, 2006-05-24 at 17:13 +0200, Maarten de Boer wrote: > Hello, > > I am looking for a cross-platform implementation of an atomic > integer. > > Under Linux, a build an c++ class "atomic" around asm/atomic.h, > (which I can use as if it where an int), but I'd like to have a > solution that also works on Windows XP and Mac OS X. > > Thanks for any suggestions, > > Maarten Reviving an ancient thread, but has anyone looked at this? http://www.hpl.hp.com/research/linux/atomic_ops/ It's pretty robust by the looks of it, nicely autotoolized, portable (to various compilers and architechtures). You can even apt-get install lib-atomicops-dev (in sid at least) Looks like exactly what I've been looking for... -DR- From a at gaydenko.com Thu Jul 13 13:56:58 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Jul 13 13:57:24 2006 Subject: [linux-audio-dev] light C++ set for WAV Message-ID: <200607132156.58993@goldspace.net> I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with few apparent methods (open/close, read/write frame(s)). Suggestions? From fons.adriaensen at skynet.be Thu Jul 13 14:07:44 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Thu Jul 13 14:07:06 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <200607132156.58993@goldspace.net> References: <200607132156.58993@goldspace.net> Message-ID: <20060713180744.GA5943@linux-1.site> On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote: > I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with > few apparent methods (open/close, read/write frame(s)). Libsndsfile is plain C, but will do what you want without any fuss. You could write a WAV specific C++ wrapper on top of this in a few minutes. -- FA Follie! Follie! Delirio vano e' questo! From jussi.laako at pp.inet.fi Thu Jul 13 14:15:14 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu Jul 13 14:15:25 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1152807187.4856.4.camel@DaveLap> References: <20060604232101.GA29257@space.twc.de> <1152651965.25882.16.camel@DaveLap> <20060711222614.GA12744@space.twc.de> <1152661389.1071.9.camel@DaveLap> <44B53746.6070903@pp.inet.fi> <1152807187.4856.4.camel@DaveLap> Message-ID: <44B68DB2.2020306@pp.inet.fi> Dave Robillard wrote: > Sorry, I /was/ referring to sem_post/sem_wait/etc. I mean havn't tried OK :) > Benchmarking message queues against pipes would be interesting, maybe > Jack could benefit if they're faster? I did some benchmarking between unix (local) sockets and message queues and found speed (roundtrip) to be over twice as fast when using message queues. In test, process A sends message "Yoohoo" to process B and process B replies "2U2" back. This is counted as a message exchange in the result. On my P4/3000 I get this kind of number: 105193.5 messages / second Nice feature of message queues is that you can get signal-style delivery using mq_notify(3). - Jussi From doj at cubic.org Thu Jul 13 15:11:31 2006 From: doj at cubic.org (Dirk Jagdmann) Date: Thu Jul 13 15:11:45 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060713180744.GA5943@linux-1.site> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> Message-ID: <44B69AE3.3050409@cubic.org> > Libsndsfile is plain C, but will do what you want without any fuss. > You could write a WAV specific C++ wrapper on top of this in a few minutes. libsndfile is superb, but sometimes you don't want to link against external libraries in your code. I have some structs/classes which I use if in-memory-handling of wav files is sufficient. You can have a look at them at: http://cubic.org/~doj/ebay/wav.tar.gz If you have to handle large files you should go the libsndfile way. -- ---> Dirk Jagdmann ^ doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org From a at gaydenko.com Thu Jul 13 15:20:32 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Jul 13 15:20:59 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060713180744.GA5943@linux-1.site> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> Message-ID: <200607132320.32963@goldspace.net> Fons, "in a few minutes" is true for *you* rather for me :-) ======= On Thursday 13 July 2006 22:07, Fons Adriaensen wrote: ======= On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote: > I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with > few apparent methods (open/close, read/write frame(s)). Libsndsfile is plain C, but will do what you want without any fuss. You could write a WAV specific C++ wrapper on top of this in a few minutes. From paul at linuxaudiosystems.com Thu Jul 13 15:21:50 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jul 13 15:22:51 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <44B69AE3.3050409@cubic.org> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <44B69AE3.3050409@cubic.org> Message-ID: <1152818510.5398.1.camel@localhost.localdomain> On Thu, 2006-07-13 at 21:11 +0200, Dirk Jagdmann wrote: > > Libsndsfile is plain C, but will do what you want without any fuss. > > You could write a WAV specific C++ wrapper on top of this in a few minutes. > > libsndfile is superb, but sometimes you don't want to link against > external libraries in your code. I have some structs/classes which I use > if in-memory-handling of wav files is sufficient. You can have a look at > them at: > http://cubic.org/~doj/ebay/wav.tar.gz > > If you have to handle large files you should go the libsndfile way. > please don't make this mistake. after 5 years of doing its own audio file handling, ardour finally switched to using libsndfile for everything. you may think you know your applications limitations and don't need libsndfile, but i claim that you're wrong. sooner or later, you will be asked for, or will realize the need for, a change that will be much easier if you just accept that the full range of functionality offered by libsndfile is the place to start. --p From a at gaydenko.com Thu Jul 13 15:22:46 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Jul 13 15:23:33 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <44B69AE3.3050409@cubic.org> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <44B69AE3.3050409@cubic.org> Message-ID: <200607132322.46123@goldspace.net> Dirk, I'm afraid I have an appetite to work with long files also. ======= On Thursday 13 July 2006 23:11, Dirk Jagdmann wrote: ======= > Libsndsfile is plain C, but will do what you want without any fuss. > You could write a WAV specific C++ wrapper on top of this in a few minutes. libsndfile is superb, but sometimes you don't want to link against external libraries in your code. I have some structs/classes which I use if in-memory-handling of wav files is sufficient. You can have a look at them at: http://cubic.org/~doj/ebay/wav.tar.gz If you have to handle large files you should go the libsndfile way. From dsbaikov at gmail.com Thu Jul 13 16:44:30 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Jul 13 16:44:37 2006 Subject: [linux-audio-dev] Creative EMU1212m In-Reply-To: <44B4F873.5030504@superbug.co.uk> References: <44B4F873.5030504@superbug.co.uk> Message-ID: <70a871c80607131344r61734a01x2d6c6c4223d52262@mail.gmail.com> Hi James, I am very interested in such a driver, but don't have a card to help you. Will your driver work with Emu 1616M? Best wishes, Dmitry. From radarsat1 at gmail.com Thu Jul 13 16:45:23 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jul 13 16:46:40 2006 Subject: [linux-audio-dev] memory-mapped wav files Message-ID: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> A thought occured to me recently... If I am writing an application which needs to stream a large wav file, I am having to write something which reserves some memory, and loads pieces of the wav file from disk on request. Say I need to be able to jump around the file a bit, I would have to detect when the piece is not available and load it in as appropriate. ... which I realized is exactly what the OS VM paging system does. So, has anyone tried using memory-mapped files for streaming audio data? (obviously, I mean, in a non-realtime thread, using a buffer). Or would this be totally inefficient? I was thinking it could really simplify programming, just directly accessing parts of the wav file as needed, and letting the OS load it up into physical memory when it wants to. Just curious. Steve From mle+la at mega-nerd.com Thu Jul 13 16:48:13 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Jul 13 16:48:25 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060713180744.GA5943@linux-1.site> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> Message-ID: <20060714064813.9cc0cab1.mle+la@mega-nerd.com> Fons Adriaensen wrote: > On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote: > > > I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with > > few apparent methods (open/close, read/write frame(s)). > > Libsndsfile is plain C, but will do what you want without any fuss. > You could write a WAV specific C++ wrapper on top of this in a few minutes. I have for some time been looking for someone to write a lightweight C++ wrapper for libsndfile that I can distribute with libsndfile. My own rather feeble first attempt is here: http://www.mega-nerd.com/tmp/sndfile.hh but I am not a fan nor a great user of C++. The wrapper should really be written by someone with a love for the language. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "An older MS internal whitepaper from August 2000 on switching Hotmail, which MS acquired in 1997, from front-end servers running FreeBSD and back-end database servers running Solaris to a whole farm running Win2K, reads like a veritable sales brochure for UNIX" -- http://www.theregister.co.uk/content/4/28226.html From dsbaikov at gmail.com Thu Jul 13 16:56:39 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Jul 13 16:56:46 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> Message-ID: <70a871c80607131356r56cc54ccy6a16fb56a588d9bd@mail.gmail.com> If you need to stream a file, mmap'ed variant will eat memory up to file size. Given large enough file, it will eat all you memory and then will begin to page out unused portions of the file. Of course, details on when and where will vary depending on VM-system implementation. The thing is, you really need only a small portion of a file. Memory mapping is useful if you need all data to be (virtually) present in RAM. Regards, Dmitry. From paul at linuxaudiosystems.com Thu Jul 13 17:14:31 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jul 13 17:15:53 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <70a871c80607131356r56cc54ccy6a16fb56a588d9bd@mail.gmail.com> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> <70a871c80607131356r56cc54ccy6a16fb56a588d9bd@mail.gmail.com> Message-ID: <1152825271.5398.4.camel@localhost.localdomain> On Fri, 2006-07-14 at 00:56 +0400, Dmitry Baikov wrote: > If you need to stream a file, mmap'ed variant will eat memory up to > file size. Given large enough file, it will eat all you memory and > then will begin to page out unused portions of the file. > Of course, details on when and where will vary depending on VM-system > implementation. > > The thing is, you really need only a small portion of a file. Memory > mapping is useful if you need all data to be (virtually) present in > RAM. moreover, in 2001-2002, it was actually slower to do i/o this way. when asked about linus said "i know and i intend to keep it that way" (paraphrasing). --p From paul at linuxaudiosystems.com Thu Jul 13 17:16:01 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jul 13 17:17:22 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060714064813.9cc0cab1.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> Message-ID: <1152825361.5398.7.camel@localhost.localdomain> On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote: > but I am not a fan nor a great user of C++. The wrapper should > really be written by someone with a love for the language. LOL! that's pretty great. "not a fan" translates in real world terms into "one of LAD's most persistent critics of almost every aspect of C+ +" :)) rock on erik, we love you anyway! From mle+la at mega-nerd.com Thu Jul 13 18:25:23 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Jul 13 18:25:33 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <1152825361.5398.7.camel@localhost.localdomain> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <1152825361.5398.7.camel@localhost.localdomain> Message-ID: <20060714082523.33c96fd5.mle+la@mega-nerd.com> Paul Davis wrote: > LOL! that's pretty great. "not a fan" translates in real world terms > into "one of LAD's most persistent critics of almost every aspect of C+ > +" :)) rock on erik, we love you anyway! Aww shucks Paul. I'm blushing :-). Maybe I should start pimping Ocaml here except that I would be the first to agre that Ocaml is really not suited to audio work :-(. Anyway, for Ocaml pimping people can read my blog: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/index.html Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Oh my god! They killed init! You bastards! From james at dis-dot-dat.net Thu Jul 13 19:06:23 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Thu Jul 13 19:06:37 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> Message-ID: <20060713230623.GN9439@fitz.Belkin> On Thu, 13 Jul, 2006 at 04:45PM -0400, Stephen Sinclair spake thus: > A thought occured to me recently... > > If I am writing an application which needs to stream a large wav file, > I am having to write something which reserves some memory, and loads > pieces of the wav file from disk on request. Say I need to be able to > jump around the file a bit, I would have to detect when the piece is > not available and load it in as appropriate. > > ... which I realized is exactly what the OS VM paging system does. > So, has anyone tried using memory-mapped files for streaming audio > data? (obviously, I mean, in a non-realtime thread, using a buffer). > Or would this be totally inefficient? > > I was thinking it could really simplify programming, just directly > accessing parts of the wav file as needed, and letting the OS load it > up into physical memory when it wants to. It's perfectly sensible. I do it a lot, because it's easy. The problem is having to load the whole thing into memory before you start, which makes things alow to start. If you're playing linearly, to solve this, you need can load it in chunks and start playing the first chunk straight away. > Just curious. > > > Steve > From radarsat1 at gmail.com Thu Jul 13 20:21:03 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jul 13 20:21:10 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <1152825271.5398.4.camel@localhost.localdomain> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> <70a871c80607131356r56cc54ccy6a16fb56a588d9bd@mail.gmail.com> <1152825271.5398.4.camel@localhost.localdomain> Message-ID: <9b3e2dc20607131721i34bfb1aegfc0d0e3d6aea12ec@mail.gmail.com> > asked about linus said "i know and i intend to keep it that > way" (paraphrasing). ah. i take it it's not a good idea then.. ;-) thanks for the answers, they were informative. steve From mle+la at mega-nerd.com Thu Jul 13 21:31:27 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Jul 13 21:31:44 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <9b3e2dc20607131721i34bfb1aegfc0d0e3d6aea12ec@mail.gmail.com> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> <70a871c80607131356r56cc54ccy6a16fb56a588d9bd@mail.gmail.com> <1152825271.5398.4.camel@localhost.localdomain> <9b3e2dc20607131721i34bfb1aegfc0d0e3d6aea12ec@mail.gmail.com> Message-ID: <20060714113127.b2961404.mle+la@mega-nerd.com> Stephen Sinclair wrote: > > asked about linus said "i know and i intend to keep it that > > way" (paraphrasing). > > ah. > i take it it's not a good idea then.. ;-) > thanks for the answers, they were informative. The other good thing about this is that once you give up mem-mapping you can just use libsndfile and have a bunch of different file formats other than WAV. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ GPLG GPLGPLGP GPLGPLGPLGP GPLGP GPL MICROSOFT GPLGP GPLGPLGPLGP GPLGPLGPL GPLGPL From S.W.Harris at ecs.soton.ac.uk Fri Jul 14 03:31:32 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Jul 14 03:31:51 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <1152825361.5398.7.camel@localhost.localdomain> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <1152825361.5398.7.camel@localhost.localdomain> Message-ID: <20060714073131.GB5357@login.ecs.soton.ac.uk> On Thu, Jul 13, 2006 at 05:16:01 -0400, Paul Davis wrote: > On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote: > > but I am not a fan nor a great user of C++. The wrapper should > > really be written by someone with a love for the language. > > LOL! that's pretty great. "not a fan" translates in real world terms > into "one of LAD's most persistent critics of almost every aspect of C+ > +" :)) rock on erik, we love you anyway! Dammit, I feel insulted ;) Though, having just part-written a huge database engine in C I am feeling warm thoughts about ObjectiveC, which maybe makes me a traitor to the cause. Go Ocaml though. - Steve From conrad.berhoerster at gmx.de Fri Jul 14 05:30:16 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Fri Jul 14 05:31:24 2006 Subject: [linux-audio-dev] diskstream and jack Message-ID: <200607141130.18669.conrad.berhoerster@gmx.de> Hello all, i try to implement the reading of audiofiles with ringbuffers. For this, i need two threads: a main process thread , which is triggered from jack every 1024 samples for example. This reads from a ringbuffer. And a worker thread which fills this ringbuffer. Now the question: - The worker thread is faster then the jackthread. (Sure, it should be). What is the usual way to pause the workerthread and wake up again, when the ringbuffer needs more data. -Which size should the ringbuffer have. - How should the ringbuffer be initilized when starting to play? - Any small program to have look into or a good inroduction into pthreads?. thanks c~ From dsbaikov at gmail.com Fri Jul 14 05:57:16 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Jul 14 05:57:23 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <200607141130.18669.conrad.berhoerster@gmx.de> References: <200607141130.18669.conrad.berhoerster@gmx.de> Message-ID: <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> Hi Conrad, > - The worker thread is faster then the jackthread. (Sure, it should be). What > is the usual way to pause the workerthread and wake up again, when the > ringbuffer needs more data. Use semaphores, Luke! > -Which size should the ringbuffer have. You need to experiment a bit, but I think 64k is sufficuent. Anyway better do this user-controlled. > - How should the ringbuffer be initilized when starting to play? > - Any small program to have look into or a good inroduction into pthreads?. You may look into my oss->jack wrapper. It's really simple and emulation of blocking io does exactly what you need. http://www.konstruktiv.org/joss/ From S.W.Harris at ecs.soton.ac.uk Fri Jul 14 06:11:53 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Jul 14 06:12:16 2006 Subject: [linux-audio-dev] memory-mapped wav files In-Reply-To: <20060713230623.GN9439@fitz.Belkin> References: <9b3e2dc20607131345l581a95ffgdcf77b99072a69d7@mail.gmail.com> <20060713230623.GN9439@fitz.Belkin> Message-ID: <20060714101153.GA9347@login.ecs.soton.ac.uk> On Fri, Jul 14, 2006 at 12:06:23 +0100, james@dis-dot-dat.net wrote: > On Thu, 13 Jul, 2006 at 04:45PM -0400, Stephen Sinclair spake thus: > > A thought occured to me recently... > > > > If I am writing an application which needs to stream a large wav file, > > I am having to write something which reserves some memory, and loads > > pieces of the wav file from disk on request. Say I need to be able to > > jump around the file a bit, I would have to detect when the piece is > > not available and load it in as appropriate. > > > > ... which I realized is exactly what the OS VM paging system does. > > So, has anyone tried using memory-mapped files for streaming audio > > data? (obviously, I mean, in a non-realtime thread, using a buffer). > > Or would this be totally inefficient? > > > > I was thinking it could really simplify programming, just directly > > accessing parts of the wav file as needed, and letting the OS load it > > up into physical memory when it wants to. > > It's perfectly sensible. I do it a lot, because it's easy. The > problem is having to load the whole thing into memory before you > start, which makes things alow to start. If you're playing linearly, > to solve this, you need can load it in chunks and start playing the > first chunk straight away. mmap-ing doesn't epxlicitly load the whole file, just bits as you request them. I wrote an app on linux that accesses large files (1-4 GB) this way recently, and the performance was certainly no worse than buffered read()s. It is very convienient, but there are some gotchas, especailly on 32bit machines where you will run out of address space really quickly. Also, my feeling is that linux is a bit conservative about how much ram it will use to map the file, though there is a hinting mechanism you can use to say what you want that mmaped region for. It's madvise(2) on Linux and BSD. I'd second what Erik said though, for audio file i/o, use a library. The ammount of i/o is really tiny, so overoptimising it is silly. - Steve From mdeboer at iua.upf.edu Fri Jul 14 06:16:03 2006 From: mdeboer at iua.upf.edu (mdeboer@iua.upf.edu) Date: Fri Jul 14 06:16:10 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <200607141130.18669.conrad.berhoerster@gmx.de> References: <200607141130.18669.conrad.berhoerster@gmx.de> Message-ID: Hi Conrad, > Now the question: > - The worker thread is faster then the jackthread. (Sure, it should be). Faster, but it might be irregular. That's what determines the ringbuffer size. > What > is the usual way to pause the workerthread and wake up again, when the > ringbuffer needs more data. I use usleep, though I am suppose that's a bit crude.. Is the ringbuffer full? Then sleep a little bit. If not, read N samples from disk and write it in the buffer. > -Which size should the ringbuffer have. I think this depends on many factors, such as hard disk speed. > - H oxw should the ringbuffer be initilized when starting to play? > - Any small program to have look into or a good inroduction into pthreads?. Another question is: how much time in advance should the workerthread start reading, in order the have the first buffer filled when the playerthread needs it? I also observed that launching a thread can take a long time (esp. on MacOSX), so I suppose you want to have the workerthread launched in advance, and make it start reading when you need it. maarten From dsbaikov at gmail.com Fri Jul 14 06:17:20 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Jul 14 06:17:32 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> References: <200607141130.18669.conrad.berhoerster@gmx.de> <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> Message-ID: <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> The short answer: #include #include #include sem_t block_wait; jack_ringbuffer_t ringbuf; init() { int max_blocks = buffer_size_in_samples/jack_block_size sem_init(&block_wait, 0, max_blocks); } jack_process() { float *out = jack_port_get_buffer(...); jack_ringbuffer_read(ringbuf, out, block_size*sizeof(float)); sem_post(&block_wait); } int exit = 0; worker_thread() { while( !exit) { sem_wait(&block_wait); read_from_disk_to_ring_buffer() } } correct program should use jack_default_audio_sample_t instead of float and should deal with buffer size changes (as well as sample rate) ;) I'll try to write a working example tonight (using libsndfile of course). Or take a look at examples/capture_client.c in jackd distribution. It uses mutex/cond but the idea is the same (semaphores are better, actually. Jack example needs a fix). Regards, Dmitry. From dsbaikov at gmail.com Fri Jul 14 06:24:49 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Jul 14 06:24:56 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> References: <200607141130.18669.conrad.berhoerster@gmx.de> <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> Message-ID: <70a871c80607140324l60b49e63x74d42788838dbcbd@mail.gmail.com> And don't forget to deal with xruns (skip one jack buffer on each xrun). From conrad.berhoerster at gmx.de Fri Jul 14 07:27:14 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Fri Jul 14 07:28:19 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: References: <200607141130.18669.conrad.berhoerster@gmx.de> Message-ID: <200607141327.15127.conrad.berhoerster@gmx.de> Hello maarten and dmitry and the rest, thanks for the quick answers. Faster means, that the workerthread is called more often than the jackthread and that the workerthread can possible fill more data then jack will need. So i try the semaphore wake thing . first i must read about semophores. never had used them before. this will take some minutes . sizu c~ Am Freitag 14 Juli 2006 12:16 schrieb mdeboer@iua.upf.edu: > Hi Conrad, > > > Now the question: > > - The worker thread is faster then the jackthread. (Sure, it should be). > > Faster, but it might be irregular. That's what determines the ringbuffer > size. > > > What > > is the usual way to pause the workerthread and wake up again, when the > > ringbuffer needs more data. > > I use usleep, though I am suppose that's a bit crude.. Is the ringbuffer > full? Then sleep a little bit. If not, read N samples from disk and write > it in the buffer. > > > -Which size should the ringbuffer have. > > I think this depends on many factors, such as hard disk speed. > > > - H oxw should the ringbuffer be initilized when starting to play? > > - Any small program to have look into or a good inroduction into > > pthreads?. > > Another question is: how much time in advance should the workerthread > start reading, in order the have the first buffer filled when the > playerthread needs it? > > I also observed that launching a thread can take a long time (esp. on > MacOSX), so I suppose you want to have the workerthread launched in > advance, and make it start reading when you need it. > > maarten From paul at linuxaudiosystems.com Fri Jul 14 08:15:02 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jul 14 08:16:09 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <200607141327.15127.conrad.berhoerster@gmx.de> References: <200607141130.18669.conrad.berhoerster@gmx.de> <200607141327.15127.conrad.berhoerster@gmx.de> Message-ID: <1152879302.5398.42.camel@localhost.localdomain> On Fri, 2006-07-14 at 13:27 +0200, conrad berh?rster wrote: > Hello maarten and dmitry and the rest, > > thanks for the quick answers. > Faster means, that the workerthread is called more often than the jackthread no, the workerthread should *not* be called more often than the jackthread. either the same frequency or slower. it should typically end up processing more data than the jack thread does per call. > and that the workerthread can possible fill more data then jack will need. > So i try the semaphore wake thing . first i must read about semophores. never from experiments done in about 2000, if you must absolutely avoid situations where one thread outruns the other, linux tends to need about a 5 second buffer if the worker thread is not running realtime (which it probably should not do). it also seemed that we got the most efficient disk i/o rates when writing chunks of about 256kB to disk rather than larger or smaller bits. From cannam at all-day-breakfast.com Fri Jul 14 08:46:22 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Fri Jul 14 08:46:19 2006 Subject: [linux-audio-dev] ANNOUNCE: Rosegarden 1.2.4 released Message-ID: <200607141346.22827.cannam@all-day-breakfast.com> ROSEGARDEN 1.2.4 RELEASED Miscellaneous locations -- Bastille day, 2006 The Rosegarden team are pleased to announce the release of version 1.2.4 of Rosegarden, an audio and MIDI sequencer and musical notation editor for Linux. http://www.rosegardenmusic.com/ The 1.2.4 release addresses several issues with the prior 1.2.3 feature release. 1.2.4 introduces no new application features. Fixes in this release include, briefly: * Avoid crash on startup if /dev/snd/seq does not exist * Fix incorrect sequencer status report ("no driver") * Fix MIDI Text Marker export * Fix text encoding for Lilypond 2.6 (UTF8 instead of ISO-8859-1) * Fix stuck notes in matrix after pressing a stop button * Fix crash when erasing a duplicated key signature * Fix crash when switching documents with a tempo editor window open * Fix incorrect sorting and insertion logic in marker editor * Fix hang in main canvas when a segment has zero duration * Fix audio preview display for repeating audio segments * Update percussion matrix when a different drum mapping is selected * Avoid crash when deleting a device with percussion matrix open * Fix matrix display for notes outside range of current key mapping * Ensure correct segment is acted on when clicking overlapping segments * Fix sequencer crash when playing back tiny audio files * Avoid display hang when too many segments overlap * Fix several build system bugs, and compilation with gcc-4.1.2 This release also includes several new MIDI device definition (.rgd) files, as well as updates for Catalan, Russian, Swedish, Czech and Italian translations, and a completely new Finnish translation from Heikki Johannes Junes. Special thanks go to Pedro Lopez-Cabanillas for preparing the release. For more information about Rosegarden and what it can do for you, please see http://www.rosegardenmusic.com/ Rosegarden is Free Software under the GNU General Public License. From conrad.berhoerster at gmx.de Fri Jul 14 08:59:16 2006 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Fri Jul 14 09:00:39 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> References: <200607141130.18669.conrad.berhoerster@gmx.de> <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> Message-ID: <200607141459.16350.conrad.berhoerster@gmx.de> Hello, ok, read the chapter semaphores! B)) Am Freitag 14 Juli 2006 12:17 schrieb Dmitry Baikov: > The short answer: > > #include > #include > #include > > sem_t block_wait; > jack_ringbuffer_t ringbuf; > > init() > { > int max_blocks = buffer_size_in_samples/jack_block_size > sem_init(&block_wait, 0, max_blocks); > } fine , I understand! > > jack_process() > { > float *out = jack_port_get_buffer(...); > jack_ringbuffer_read(ringbuf, out, block_size*sizeof(float)); > sem_post(&block_wait); > } Just to be sure. This means every Port has his own Ringbuffer, right? So stereo needs two, 5.1 needs 6 ? But i only need one sem_post for all, because i should avoid to have different readpositions in my RingBuffers. And if i understand Paul Davis in the right way, i never read more data as jack needed, and this isn't more as 1 or 2k - normally. ??! sizu c~ From James at superbug.co.uk Fri Jul 14 09:13:01 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Fri Jul 14 09:13:09 2006 Subject: [linux-audio-dev] Creative EMU1212m In-Reply-To: <70a871c80607131344r61734a01x2d6c6c4223d52262@mail.gmail.com> References: <44B4F873.5030504@superbug.co.uk> <70a871c80607131344r61734a01x2d6c6c4223d52262@mail.gmail.com> Message-ID: <44B7985D.5090403@superbug.co.uk> Dmitry Baikov wrote: > Hi James, > > I am very interested in such a driver, but don't have a card to help you. > Will your driver work with Emu 1616M? > > > Best wishes, > > Dmitry. I don't know. I guess this will be a try it and see. I only have the emu1212m. I will get the Audio Dock and sync card soon, so that will cover the emu1820m and the sync card. Hopefully, the 1616M is similar. James From torbenh at gmx.de Fri Jul 14 10:19:10 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Jul 14 10:20:20 2006 Subject: [linux-audio-dev] [ANN] netjack-0.12 - Low Latency Network Audio Driver Message-ID: <20060714141909.GA7913@mobilat> hi. netjack-0.12 is released. Netjack is a jack-driver which uses the network card. On the other end of the network there is a normal jack-client. So its possible, to share a single soundcard between several laptops. This release finally handles the packet disordering UDP does. Thus high channel counts can now be achieved. However a 24ch in/out link over 100Mbit gave me a major "net xrun" storm on vanilla 2.6.15 kernel. At a roundtrip latency of 2.9ms that is. It was reliable with 5.8ms. 16 channels gave me some "net xruns", which i could not hear though. i expect this performance to increase when using an rt-kernel with the network-irq set to rt-prio. So please report back. Additionally to the audio transport, netjack provides sample accurate transport syncronisation. The roundtrip latency is compensated for. get it while its hot at: http://sourceforge.net/project/showfiles.php?group_id=140191 there is no link on http://netjack.sf.net because the project shell servers are down. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From dsbaikov at gmail.com Fri Jul 14 11:14:10 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Jul 14 11:14:16 2006 Subject: [linux-audio-dev] diskstream and jack In-Reply-To: <200607141459.16350.conrad.berhoerster@gmx.de> References: <200607141130.18669.conrad.berhoerster@gmx.de> <70a871c80607140257vd53d11fhf68bb3475cb6c10d@mail.gmail.com> <70a871c80607140317i4757e6d6yaab2e0ca0843be4b@mail.gmail.com> <200607141459.16350.conrad.berhoerster@gmx.de> Message-ID: <70a871c80607140814t78654e4dm780da21222c61381@mail.gmail.com> > This means every Port has his own Ringbuffer, right? So stereo needs two, 5.1 > needs 6 ? > But i only need one sem_post for all, because i should avoid to have different > readpositions in my RingBuffers. As you wish, you may have one interleaved ring buffer. But only one semaphore to rule them all. > And if i understand Paul Davis in the right way, i never read more data as > jack needed, and this isn't more as 1 or 2k - normally. ??! Vice versa. You'd better cache more data (about 5 seconds, according to Paul), as your disk-thread is not realtime (and should not be) and may get stuck a bit. From pieterp at joow.be Fri Jul 14 12:24:51 2006 From: pieterp at joow.be (Pieter Palmers) Date: Fri Jul 14 12:24:53 2006 Subject: Sourceforge issues WAS: [linux-audio-dev] [ANN] netjack-0.12 - Low Latency Network Audio Driver In-Reply-To: <20060714141909.GA7913@mobilat> References: <20060714141909.GA7913@mobilat> Message-ID: <44B7C553.9050608@joow.be> torbenh@gmx.de wrote: > there is no link on http://netjack.sf.net because the project shell > servers are down. Probably not the cause (as the shell service downtime is displayed on the status page), but should you run into strange issues with SF this can be interesting: ( 2006-07-13 09:23:52 - Project CVS Service, Project Shell Service, Project Subversion (SVN) Service, SourceForge.net Web Site ) A recent kernel exploit was released that allowed a non admin user to escalate privileges on the host pr-shell1. We urge all users who frequent this host to change their password immediately and check their project group space for any tampering. As a precaution, we have blocked access to all project resources by password until the user resets their password. After the password has been reset, project resources should be accessible within 5 minutes. I really wonder why they don't inform their users any better. Greets, Pieter PS: Thx to Jonathan Woithe for pointing this out on freebob-devel. From torbenh at gmx.de Fri Jul 14 15:41:22 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Jul 14 15:42:20 2006 Subject: Sourceforge issues WAS: [linux-audio-dev] [ANN] netjack-0.12 - Low Latency Network Audio Driver In-Reply-To: <44B7C553.9050608@joow.be> References: <20060714141909.GA7913@mobilat> <44B7C553.9050608@joow.be> Message-ID: <20060714194122.GA27392@mobilat> On Fri, Jul 14, 2006 at 06:24:51PM +0200, Pieter Palmers wrote: > torbenh@gmx.de wrote: > > >there is no link on http://netjack.sf.net because the project shell > >servers are down. > > Probably not the cause (as the shell service downtime is displayed on > the status page), but should you run into strange issues with SF this > can be interesting: > > ( 2006-07-13 09:23:52 - Project CVS Service, Project Shell Service, > Project Subversion (SVN) Service, SourceForge.net Web Site ) A recent > kernel exploit was released that allowed a non admin user to escalate > privileges on the host pr-shell1. We urge all users who frequent this > host to change their password immediately and check their project group > space for any tampering. As a precaution, we have blocked access to all > project resources by password until the user resets their password. > After the password has been reset, project resources should be > accessible within 5 minutes. Project Shell Service: Offline - Unplanned Downtime In-Progress Last updated: 2006-07-12 Pacific still there. the host refuses connections. i use key authentication. well... lets just sit and wait... i should have used the FRS anyways ;) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From jonobacon at gmail.com Sun Jul 16 09:07:13 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Jul 16 09:07:21 2006 Subject: [linux-audio-dev] Hello and Python bindings for LADSPA Message-ID: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> Hi all, My name is Jono Bacon (www.jonobacon.org) and I am one of the developers working on Jokosher, a GStreamer based multi-track audio editor written in Python for the GNOME desktop. Jokosher is designed to be really simple to use, and we release our first 0.1 release on Saturday. You can find out more at www.jokosher.org. although the brand new, much improved site is released on Saturday too. I am also one of the members of LUGRadio. Anyway, for Jokosher 0.2 I want to include LADSPA support. From what I understand, LADSPA not only provides an audio layer, but also a GUI layer, so the widgets in the plug-in can be displayed in the host toolkit. I know there is an antiquated GStreamer bridge for LADSPA, but in terms of getting the GUI elements to display, I assume I need Python bindings. Do such bindings exist? Oh, and by the way, if you are in the UK, we are running an event called LUGRadio Live 2006 with over 40 speakers, a room full of exhibitors, lots of BOF sessions and a party. It is held in Wolverhampton on the 22nd and 23rd July (next weekend). It would be great to see a fraternity of Linux audio developers there. Anyone want to come along? See www.lugradio.org/live/2006 for more details. Thanks folks! Jono From lars.luthman at gmail.com Sun Jul 16 09:19:35 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 09:19:44 2006 Subject: [linux-audio-dev] Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> Message-ID: <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 14:07 +0100, Jono Bacon wrote: > Anyway, for Jokosher 0.2 I want to include LADSPA support. From what I > understand, LADSPA not only provides an audio layer, but also a GUI > layer, so the widgets in the plug-in can be displayed in the host > toolkit. It does not. Where did you read that? DSSI has support for GUIs, but there the GUIs are separate programs that communicate with the host using OSC, there are no widgets in the plugins. LADSPA plugins only know about signal processing, nothing about GUIs. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/4da7af18/attachment.bin From jonobacon at gmail.com Sun Jul 16 09:24:00 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Jul 16 09:24:07 2006 Subject: [linux-audio-dev] Hello and Python bindings for LADSPA In-Reply-To: <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> Hi Lars, > DSSI has support for GUIs, but there the GUIs are separate programs that > communicate with the host using OSC, there are no widgets in the > plugins. > > LADSPA plugins only know about signal processing, nothing about GUIs. Oh, I was under the impression that each LADSPA plugin had a toolkit independent spec file (such as an XML) which should be parsed and rendered in the host toolkit. I must have read about something else. So how do LADSPA plugins deal with GUI controls? Also, are you aware of any Python bindings? Thanks Lars. Jono From lars.luthman at gmail.com Sun Jul 16 09:29:23 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 09:29:30 2006 Subject: [linux-audio-dev] Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> Message-ID: <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 14:24 +0100, Jono Bacon wrote: > Hi Lars, > > > DSSI has support for GUIs, but there the GUIs are separate programs that > > communicate with the host using OSC, there are no widgets in the > > plugins. > > > > LADSPA plugins only know about signal processing, nothing about GUIs. > > Oh, I was under the impression that each LADSPA plugin had a toolkit > independent spec file (such as an XML) which should be parsed and > rendered in the host toolkit. I must have read about something else. > So how do LADSPA plugins deal with GUI controls? Some plugins (far from all or even most) have an associated RDF/XML file that describe some properties of the plugin and its parameters. I don't know how useful they would be for GUI rendering, I have never tried writing anything that uses them. LADSPA plugins themselves usually don't care about GUIs at all, it's up to the plugin host to create a GUI for the plugin. > Also, are you aware of any Python bindings? No, sorry. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/5236e6a7/attachment.bin From jonobacon at gmail.com Sun Jul 16 10:05:33 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Jul 16 10:05:41 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> On 7/16/06, Lars Luthman wrote: > Some plugins (far from all or even most) have an associated RDF/XML file > that describe some properties of the plugin and its parameters. I don't > know how useful they would be for GUI rendering, I have never tried > writing anything that uses them. Right, so the xml file is not mandated to represent gui info. I see. > LADSPA plugins themselves usually don't care about GUIs at all, it's up > to the plugin host to create a GUI for the plugin. So if i understand you correctly, each host needs to present a specific gui for plugins. Doesn't this make ladspa not partcularly 'pluggable' if the host needs to know about plugins in the first place? I thought the point of ladspa was that you could just install third party pluginsand the gui would just work. Thanks, jono From lars.luthman at gmail.com Sun Jul 16 10:28:18 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 10:28:28 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> Message-ID: <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 15:05 +0100, Jono Bacon wrote: > So if i understand you correctly, each host needs to present a > specific gui for plugins. Doesn't this make ladspa not partcularly > 'pluggable' if the host needs to know about plugins in the first > place? I thought the point of ladspa was that you could just install > third party pluginsand the gui would just work. It does "just work", you just get generic GUIs instead of plugin-specific ones. There are some "port hints" in the plugin that specify whether a certain parameter is interpreted as an integer, a boolean, has upper or lower bounds etc that the host can use to decide whether it should use a spinbutton or a checkbox or a slider or something else for that parameter. You could look at some existing LADSPA hosts with GUIs (e.g. JACK-rack, Ardour, Om, Hydrogen) to see how they do it. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/05d4660a/attachment.bin From jonobacon at gmail.com Sun Jul 16 10:38:59 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Jul 16 10:39:11 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> Hi Lars, > It does "just work", you just get generic GUIs instead of > plugin-specific ones. But surely the GUI is bound to a certain list of plugins. So, when we get LADSPA support in Jokosher, because we need to make the GUI for the plugins, we need to basically decide on a list of included plugins and create the GUIs. Surely this limits the ability for the user to just install a plugin pack as we won't have GUI for those plugins? Correct me if I am wrong on this, I am still very new around here. :P Oh, and I read that someone was working on an XML DTD for plugin GUIs - what is the current progress on this? I could not find anything out about it on the LADSPA site. > There are some "port hints" in the plugin that specify whether a certain > parameter is interpreted as an integer, a boolean, has upper or lower > bounds etc that the host can use to decide whether it should use a > spinbutton or a checkbox or a slider or something else for that > parameter. I assume that the GStreamer bridge exposes these port hints as gettable properties. I will check with them. > You could look at some existing LADSPA hosts with GUIs (e.g. JACK-rack, > Ardour, Om, Hydrogen) to see how they do it. I plan on doing this. I also noticed there is dsptools which offers python bindings to LADSPA among other things. Thanks for imparting your wisdom Lars. :) Jono From lars.luthman at gmail.com Sun Jul 16 10:44:46 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 10:44:53 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> Message-ID: <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 15:38 +0100, Jono Bacon wrote: > Hi Lars, > > > It does "just work", you just get generic GUIs instead of > > plugin-specific ones. > > But surely the GUI is bound to a certain list of plugins. So, when we > get LADSPA support in Jokosher, because we need to make the GUI for > the plugins, we need to basically decide on a list of included plugins > and create the GUIs. No, why? You generate the GUIs at runtime - if you load a plugin that has 4 "boolean" parameters you add 4 checkboxes or levers or whatever you have to your plugin GUI, and if you load a plugin that has a single parameter bounded between 0 and 6 you create a slider that slides from 0 to 6 and add it to your plugin GUI. > Oh, and I read that someone was working on an XML DTD for plugin GUIs > - what is the current progress on this? I could not find anything out > about it on the LADSPA site. I don't know anything about that. You could try searching this list or LAD. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/7ef3a8b8/attachment.bin From lars.luthman at gmail.com Sun Jul 16 10:50:51 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 10:50:59 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1153061451.3621.31.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 16:44 +0200, Lars Luthman wrote: > I don't know anything about that. You could try searching this list or > LAD. I meant LAU. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/ddcc98ed/attachment-0001.bin From jonobacon at gmail.com Sun Jul 16 11:09:45 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Sun Jul 16 11:09:52 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> On 7/16/06, Lars Luthman wrote: > No, why? You generate the GUIs at runtime - if you load a plugin that > has 4 "boolean" parameters you add 4 checkboxes or levers or whatever > you have to your plugin GUI, and if you load a plugin that has a single > parameter bounded between 0 and 6 you create a slider that slides from 0 > to 6 and add it to your plugin GUI. Right, so I would detect the capabilities of ports and construct a GUI around that. I get what you mean. Thanks, Jono From _ at whats-your.name Sun Jul 16 13:23:05 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 16 13:23:07 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> Message-ID: <20060716172305.GB20511@replic.net> > Right, so I would detect the capabilities of ports and construct a GUI > around that. I get what you mean. if gstreamer doesnt wrap all the port-hint query stuff and you dont feel like implementing it, in LV2 you can parse the port schema with eg Redland Python bindings. presumably the one-way send-params-to-gstreamer is easier to build than a roundtrip.. From _ at whats-your.name Sun Jul 16 13:28:18 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 16 13:28:20 2006 Subject: [linux-audio-dev] LV2 Turtle requirement Message-ID: <20060716172818.GC20511@replic.net> i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable turtle format. my main question is, whether this will be transformed to RDF-XML during 'make install' or perhaps by the developer themselves (Eg, similar to leaving a configure script around for those who dont have autoconf). mainly beacuse, it seems RDF-XML is the dominant serialization format, and having this additional dependency stand in the way means, at the very least one can't use Pyrple out of the box. i installed Redland and the Ruby and TCL bindings, and both conspicuously left out the "Redland::Parser.turtle" method, presumably beacuse i dont have it installed (and it's not in portage...) cheers From lars.luthman at gmail.com Sun Jul 16 13:35:19 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sun Jul 16 13:35:28 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <20060716172818.GC20511@replic.net> References: <20060716172818.GC20511@replic.net> Message-ID: <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sun, 2006-07-16 at 17:28 +0000, carmen wrote: > i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable > turtle format. my main question is, whether this will be transformed to RDF-XML > during 'make install' or perhaps by the developer themselves (Eg, similar to > leaving a configure script around for those who dont have autoconf). I hope not - I've already written a host that parses Turtle and only Turtle. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060716/5ecbe672/attachment.bin From _ at whats-your.name Sun Jul 16 13:38:15 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 16 13:38:16 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060716172818.GC20511@replic.net> <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <20060716173815.GD20511@replic.net> On Sun Jul 16, 2006 at 07:35:19PM +0200, Lars Luthman wrote: > On Sun, 2006-07-16 at 17:28 +0000, carmen wrote: > > i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable > > turtle format. my main question is, whether this will be transformed to RDF-XML > > during 'make install' or perhaps by the developer themselves (Eg, similar to > > leaving a configure script around for those who dont have autoconf). > > I hope not - I've already written a host that parses Turtle and only > Turtle. you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. From _ at whats-your.name Sun Jul 16 13:52:15 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 16 13:52:15 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <20060716173815.GD20511@replic.net> References: <20060716172818.GC20511@replic.net> <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <20060716173815.GD20511@replic.net> Message-ID: <20060716175215.GE20511@replic.net> > you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. my main issue is the only RDF toolkit in Portage didnt properly include Turtle parsing. which means theres an even slimmer chance of such things existing in Debian, Fedora, etc. now i must investigate why this is the case.. on top of that, a lot of the ideas wrt interactive documentation (eg wiki-style annotations of what ports actually do, user presets, etc) on the web would be easier since RDF/XML is readily embeddable into XHTML. throwing a 'raptor blahblah.ttl > blahblah.xml' in a SConstruct is praobly easier than having to continually think about it on the server side (eg in PHP) or in JavaScript.. From smcameron at yahoo.com Sun Jul 16 15:14:45 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sun Jul 16 15:14:51 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? Message-ID: <20060716191445.56075.qmail@web33011.mail.mud.yahoo.com> So, I've got a yamaha motif rack, and the manual (which is here, btw: http://www2.yamaha.co.jp/manual/pdf/emi/english/synth/MOTIFRACKE2.pdf ) On P. 46 of that manual describes how, and it seems like it should be brain dead simple. There's a basic recieve channel on the Motif Rack, (it claims that it is set to "1" -- I don't know if that is zero or one based, so I tried both. I think, if I send a byte sequence like: 0xb1 0xf3 0x03 0xc1 0x07 (or maybe substitute 0 for any 1 in the above, I tried them all) It ought to do something. I *can* change patches within a bank, that is the Sending 0xc0 0x25 will change the current preset. Just can't figure out the bank change thing. Well, I'm retarded, or the spec is wrong, or the motif is broken... I think I must be retarded. At the moment, I've reduced things to a few lines of C that just open up /dev/snd/midiC1D0 and write some bytes out -- I know that much works because note-on and patch change work. Just wondering if anybody else out there has a Motif and if they've ever gotten it to change banks. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rncbc at rncbc.org Sun Jul 16 15:52:01 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sun Jul 16 15:53:24 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? In-Reply-To: <20060716191445.56075.qmail@web33011.mail.mud.yahoo.com> References: <20060716191445.56075.qmail@web33011.mail.mud.yahoo.com> Message-ID: <44BA98E1.6050607@rncbc.org> Stephen Cameron wrote: > So, I've got a yamaha motif rack, and the manual > (which is here, btw: > http://www2.yamaha.co.jp/manual/pdf/emi/english/synth/MOTIFRACKE2.pdf ) > > On P. 46 of that manual describes how, and it seems like it should > be brain dead simple. There's a basic recieve channel on the > Motif Rack, (it claims that it is set to "1" -- I don't know if > that is zero or one based, so I tried both. > > I think, if I send a byte sequence like: > > 0xb1 0xf3 0x03 0xc1 0x07 > > (or maybe substitute 0 for any 1 in the above, I tried them all) > > It ought to do something. > > I *can* change patches within a bank, that is the > Sending 0xc0 0x25 will change the current preset. > > Just can't figure out the bank change thing. Well, > I'm retarded, or the spec is wrong, or the motif is broken... > > I think I must be retarded. > > At the moment, I've reduced things to a few lines of C > that just open up /dev/snd/midiC1D0 and write some > bytes out -- I know that much works because note-on and > patch change work. > > Just wondering if anybody else out there has a Motif and > if they've ever gotten it to change banks. > You're probably missing the required Bank Select control changes (MSB CC#=0 and LSB CC#=32) which should precede the proper Program Change message. This is standard MIDI specification, not specific to your device, and its perfectly stated on the manual page you mentioned. Bye now. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From S.W.Harris at ecs.soton.ac.uk Sun Jul 16 18:06:34 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Jul 16 18:07:16 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <20060716173815.GD20511@replic.net> References: <20060716172818.GC20511@replic.net> <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <20060716173815.GD20511@replic.net> Message-ID: <20060716220634.GB26898@login.ecs.soton.ac.uk> On Sun, Jul 16, 2006 at 05:38:15PM +0000, carmen wrote: > On Sun Jul 16, 2006 at 07:35:19PM +0200, Lars Luthman wrote: > > On Sun, 2006-07-16 at 17:28 +0000, carmen wrote: > > > i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable > > > turtle format. my main question is, whether this will be transformed to RDF-XML > > > during 'make install' or perhaps by the developer themselves (Eg, similar to > > > leaving a configure script around for those who dont have autoconf). > > > > I hope not - I've already written a host that parses Turtle and only > > Turtle. > > you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. I've never heard of Fresnel, but Protege can read N3, which is a superset of Turtle. There's some pretty strong anti-XML feeling in this community, and Turtle was less contraversial all round. Personally I prefer reading and writing Turtle to RDF/XML, which is pretty hideous. If your tool of choice can't read Turtle directly, just use something like rapper to turn it into RDF/XML first. - Steve From S.W.Harris at ecs.soton.ac.uk Sun Jul 16 18:12:19 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Jul 16 18:12:38 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <20060716175215.GE20511@replic.net> References: <20060716172818.GC20511@replic.net> <1153071319.3621.34.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <20060716173815.GD20511@replic.net> <20060716175215.GE20511@replic.net> Message-ID: <20060716221219.GC26898@login.ecs.soton.ac.uk> On Sun, Jul 16, 2006 at 05:52:15PM +0000, carmen wrote: > > you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. > > my main issue is the only RDF toolkit in Portage didnt properly include Turtle parsing. which means theres an even slimmer chance of such things existing in Debian, Fedora, etc. now i must investigate why this is the case.. on top of that, a lot of the ideas wrt interactive documentation (eg wiki-style annotations of what ports actually do, user presets, etc) on the web would be easier since RDF/XML is readily embeddable into XHTML. throwing a 'raptor blahblah.ttl > blahblah.xml' in a SConstruct is praobly easier than having to continually think about it on the server side (eg in PHP) or in JavaScript.. You can't "easily" embed RDF/XML into XHTML, you can use RDF/A or GRDDL, but that's different. You can apply the same conversion argument just as well the other way round. I have some PHP scripts that conneg LV2 turtle files into HTML (still very primitive) or RDF/XML as required, it's not exactly hard. - Steve From S.W.Harris at ecs.soton.ac.uk Sun Jul 16 18:17:50 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Jul 16 18:18:20 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> Message-ID: <20060716221750.GD26898@login.ecs.soton.ac.uk> On Sun, Jul 16, 2006 at 03:38:59PM +0100, Jono Bacon wrote: > Hi Lars, > > >It does "just work", you just get generic GUIs instead of > >plugin-specific ones. > > But surely the GUI is bound to a certain list of plugins. So, when we > get LADSPA support in Jokosher, because we need to make the GUI for > the plugins, we need to basically decide on a list of included plugins > and create the GUIs. Surely this limits the ability for the user to > just install a plugin pack as we won't have GUI for those plugins? > Correct me if I am wrong on this, I am still very new around here. :P > > Oh, and I read that someone was working on an XML DTD for plugin GUIs > - what is the current progress on this? I could not find anything out > about it on the LADSPA site. It has been proposed several times, but it's not a particularly good idea IMHO. I was in favour of it for a bit. - Steve From drobilla at connect.carleton.ca Sun Jul 16 20:33:08 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jul 16 20:34:03 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <20060716172818.GC20511@replic.net> References: <20060716172818.GC20511@replic.net> Message-ID: <1153096388.11279.6.camel@DaveLap> On Sun, 2006-07-16 at 17:28 +0000, carmen wrote: > i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable turtle format. my main question is, whether this will be transformed to RDF-XML during 'make install' or perhaps by the developer themselves (Eg, similar to leaving a configure script around for those who dont have autoconf). > > mainly beacuse, it seems RDF-XML is the dominant serialization format, and having this additional dependency stand in the way means, at the very least one can't use Pyrple out of the box. i installed Redland and the Ruby and TCL bindings, and both conspicuously left out the "Redland::Parser.turtle" method, presumably beacuse i dont have it installed (and it's not in portage...) > > cheers Why would you want to take a nice, readable format, and translate it into the confusing bloated mess that is RDF/XML automatically and by default? Because some particular toolkit can't read N3/Turtle yet? Silly. If the toolkit you want to use sucks, then you can convert the N3/Turtle to RDF/XML yourself easily enough... -DR- From loki.davison at gmail.com Sun Jul 16 22:45:21 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Jul 16 22:45:28 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> Message-ID: On 7/17/06, Jono Bacon wrote: > On 7/16/06, Lars Luthman wrote: > > No, why? You generate the GUIs at runtime - if you load a plugin that > > has 4 "boolean" parameters you add 4 checkboxes or levers or whatever > > you have to your plugin GUI, and if you load a plugin that has a single > > parameter bounded between 0 and 6 you create a slider that slides from 0 > > to 6 and add it to your plugin GUI. > > Right, so I would detect the capabilities of ports and construct a GUI > around that. I get what you mean. > > Thanks, > > Jono > Have you looked into LV2 btw? It will be ready soon. For your kind of app i'm assuming DSSI support would be very handy. How well does jokosher work low latency? Which python jack bindings are you using? Have you got dsp and gui process separation? I was thinking about a DAW/midi/osc sequencer with this kind of arch, python for gui, c for dsp stuff, process separated and communication over OSC. Loki From smcameron at yahoo.com Sun Jul 16 22:58:43 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sun Jul 16 22:58:49 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? In-Reply-To: <44BA98E1.6050607@rncbc.org> Message-ID: <20060717025843.60649.qmail@web33002.mail.mud.yahoo.com> --- Rui Nuno Capela wrote: [...] > You're probably missing the required Bank Select control changes (MSB > CC#=0 and LSB CC#=32) which should precede the proper Program Change > message. This is standard MIDI specification, not specific to your > device, and its perfectly stated on the manual page you mentioned. I'm sure the manual is fine for someone who already knows how these things work. For me, it left something to be desired. A few examples would have been a great help. For the benefit of, well, of probably nobody, maybe myself when I forget this and have to figure it out again, I will record what I found out anyway. The Motif has a couple parameters under the Utility/MIDI menu on the front panel. There's a setting for the channel on which to recieve basic messages. Set this to 1. (That means it will recieve them on channel 0, not 1, oddly enough.) There are settings for BankChange and Patch Change. Make sure they are "on". The manual fails to mention what the Bank Change message is (probably because it is "standard MIDI stuff.") It is 0xB0 (or 0xBn, where n is the channel the device receives basic messages on.) It requires TWO bank select commands to select a bank. One to set the MSB, and one to set the LSB. You can't set them both with one command (which is what I was trying to do that didn't work.) 0xB0 0x00 0xf3 // 0xB0 0x00 means "set bank MSB" 0xf3 is the // value to set it to. 0xB0 0x20 0x01 // 0xB0 0x20 means "set bank LSB" 0x01 is the // value to set it to. 0xC0 0x01 // Patch change to preset 0x01 of the previously // selected bank MSB/LSB. That's what a halfway decent explanation looks like, provided my current understanding is correct. (It's correct enough that my program works now.) Thanks -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From clemens at ladisch.de Mon Jul 17 04:00:44 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Jul 17 04:00:54 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? In-Reply-To: <20060717025843.60649.qmail@web33002.mail.mud.yahoo.com> References: <44BA98E1.6050607@rncbc.org> <20060717025843.60649.qmail@web33002.mail.mud.yahoo.com> Message-ID: <20060717080044.GA4419@turing.informatik.uni-halle.de> Stephen Cameron wrote: > The manual fails to mention what the Bank Change message is > (probably because it is "standard MIDI stuff.") It is 0xB0 > (or 0xBn, where n is the channel the device receives basic > messages on.) Bx is the Control Change command. The two halves of the bank number are just two controllers, 0 and 32. > It requires TWO bank select commands to select a bank. One > to set the MSB, and one to set the LSB. You can't set them > both with one command (which is what I was trying to do that > didn't work.) You can omit the command byte (called "status" in MIDI) when it is identical to the last one, so you could use B0 00 msb 20 lsb This feature is called "running status". > 0xB0 0x00 0xf3 // 0xB0 0x00 means "set bank MSB" 0xf3 is the > // value to set it to. This is not a valid MIDI command. The highest bit of each byte is used to differentitate between command and data bytes, so data bytes must be no greater than 127 (0x7f). The manual should document somewhere what the MSB value for this bank is, but it's certainly not F3. To learn more about MIDI, have a look (or more than one) at . HTH Clemens From S.W.Harris at ecs.soton.ac.uk Mon Jul 17 04:23:46 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jul 17 04:24:14 2006 Subject: [linux-audio-dev] LV2 Turtle requirement In-Reply-To: <1153096388.11279.6.camel@DaveLap> References: <20060716172818.GC20511@replic.net> <1153096388.11279.6.camel@DaveLap> Message-ID: <20060717082346.GC1485@login.ecs.soton.ac.uk> On Sun, Jul 16, 2006 at 08:33:08 -0400, Dave Robillard wrote: > On Sun, 2006-07-16 at 17:28 +0000, carmen wrote: > > i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable turtle format. my main question is, whether this will be transformed to RDF-XML during 'make install' or perhaps by the developer themselves (Eg, similar to leaving a configure script around for those who dont have autoconf). > > > > mainly beacuse, it seems RDF-XML is the dominant serialization format, and having this additional dependency stand in the way means, at the very least one can't use Pyrple out of the box. i installed Redland and the Ruby and TCL bindings, and both conspicuously left out the "Redland::Parser.turtle" method, presumably beacuse i dont have it installed (and it's not in portage...) > > > > cheers > > Why would you want to take a nice, readable format, and translate it > into the confusing bloated mess that is RDF/XML automatically and by > default? Because some particular toolkit can't read N3/Turtle yet? > Silly. > > If the toolkit you want to use sucks, then you can convert the N3/Turtle > to RDF/XML yourself easily enough... To be fair, Turtle is relativly new, whereas RDF/XML is about 10 years old. There are some tools that don't yet handle Turtle. I agree about the conversion though. Turtle is much more popular in these parts, and the conversion is easily done either way. - Steve From rncbc at rncbc.org Mon Jul 17 05:01:30 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Mon Jul 17 05:02:32 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? In-Reply-To: <20060717025843.60649.qmail@web33002.mail.mud.yahoo.com> References: <44BA98E1.6050607@rncbc.org> <20060717025843.60649.qmail@web33002.mail.mud.yahoo.com> Message-ID: <24497.195.245.190.94.1153126890.squirrel@www.rncbc.org> On Mon, July 17, 2006 03:58, Stephen Cameron wrote: > --- Rui Nuno Capela wrote: > [...] > >> You're probably missing the required Bank Select control changes (MSB >> CC#=0 and LSB CC#=32) which should precede the proper Program Change >> message. This is standard MIDI specification, not specific to your >> device, and its perfectly stated on the manual page you mentioned. > > I'm sure the manual is fine for someone who already knows how > these things work. For me, it left something to be desired. A few > examples would have been a great help. > > For the benefit of, well, of probably nobody, maybe > myself when I forget this and have to figure it out again, I will record > what I found out anyway. > > The Motif has a couple parameters under the Utility/MIDI menu on the > front panel. There's a setting for the channel on which to recieve basic > messages. Set this to 1. (That means it will recieve them on channel 0, > not 1, oddly enough.) There are settings for BankChange and Patch Change. > Make sure they are "on". > > > The manual fails to mention what the Bank Change message is > (probably because it is "standard MIDI stuff.") It is 0xB0 > (or 0xBn, where n is the channel the device receives basic > messages on.) > > It requires TWO bank select commands to select a bank. One > to set the MSB, and one to set the LSB. You can't set them both with one > command (which is what I was trying to do that didn't work.) > > 0xB0 0x00 0xf3 // 0xB0 0x00 means "set bank MSB" 0xf3 is the > // value to set it to. > > > 0xB0 0x20 0x01 // 0xB0 0x20 means "set bank LSB" 0x01 is the > // value to set it to. > > > 0xC0 0x01 // Patch change to preset 0x01 of the previously > // selected bank MSB/LSB. > > > That's what a halfway decent explanation looks like, provided > my current understanding is correct. (It's correct enough that my program > works now.) > Looking into the page of the manual, you can see on the Bank Select table all the available BANK SEL and PROG CHANGE values for your device. The correct sequences would be: 1. BANK SEL MSB (Control Change #0) 0xB0 0x00 2. BANK SEL LSB (Control Change #32): 0xB0 0x20 3. PROG CHANGE: 0xC0 Where the , and values should be taken from the table, in manual p.46, columns MSB (HEX), LSB (HEX) and Program No. respectively. You seem to had it almost there, but 0xf3 doesn't look like a valid value for . It's not part of the available bank selections nor its a valid MIDI data value. Every MIDI data value must be in the 0x00 to 0x7f range [0,127]. As an example, this looks like being correct to select the 2nd program patch of the "Normal Voice", "Preset 2" bank: 0xB0 0x00 0x3f 0xB0 0x20 0x01 0xC0 0x01 or, using running-status: 0xB0 0x00 0x3f 0x20 0x01 0xC0 0x01 Note that I'm using MIDI channel address 0 in this example. Depending on your receive channel, you're ought to try on channel 1, and the above sequence should be: 0xB1 0x00 0x3f 0xB1 0x20 0x01 0xC1 0x01 Hope this got a bit clearer. Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From Jan.Weil at web.de Mon Jul 17 06:00:07 2006 From: Jan.Weil at web.de (Jan Weil) Date: Mon Jul 17 06:00:14 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF Message-ID: <44BB5FA7.8060605@web.de> Apparently, a Sound BOF took place at GUADEC 2006 . Slides that were presented: It seems that PulseAudio , formerly known as Polypaudio, could be (is?) GNOME's new audio server of choice replacing esd. via -> From voidcreature at paradise.net.nz Mon Jul 17 06:09:34 2006 From: voidcreature at paradise.net.nz (voidcreature@paradise.net.nz) Date: Mon Jul 17 06:10:55 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <44BB5FA7.8060605@web.de> References: <44BB5FA7.8060605@web.de> Message-ID: <200607172209.34722.voidcreature@paradise.net.nz> On Monday 17 July 2006 22:00, Jan Weil wrote: > Apparently, a Sound BOF took place at GUADEC 2006 > . Slides that were presented: > > > It seems that PulseAudio , formerly known as > Polypaudio, could be (is?) GNOME's new audio server of choice replacing > esd. > > via -> > wow, that looks pretty good. i'm off to write an arts backend to feed into pulseaudio right away. so i can have noatun->arts->pulseaudio->alsa->jack->alsa->soundcard i wonder if i somehow get esd into that chain somewhere too? because you can never have too many sound servers. From jonobacon at gmail.com Mon Jul 17 06:38:37 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Mon Jul 17 06:38:43 2006 Subject: [linux-audio-dev] Re: Hello and Python bindings for LADSPA In-Reply-To: References: <1c3fe48e0607160607y293fd580hdcd3ae4b003f22ce@mail.gmail.com> <1153055975.3621.11.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160624v6c72ec68y3d8a2238dad4fc73@mail.gmail.com> <1153056563.3621.15.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160705x289515rfaee9acbf4ecf4ad@mail.gmail.com> <1153060098.3621.24.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160738s1ae7c069i4a715dcb53e8ccd1@mail.gmail.com> <1153061086.3621.29.camel@c-1075e055.456-1-64736c13.cust.bredbandsbolaget.se> <1c3fe48e0607160809i34f97ac1md72d0cd4fcc042c6@mail.gmail.com> Message-ID: <1c3fe48e0607170338n92d3fc3qc3fd08a1a60c7a82@mail.gmail.com> On 7/17/06, Loki Davison wrote: > Have you looked into LV2 btw? It will be ready soon. For your kind of > app i'm assuming DSSI support would be very handy. How well does > jokosher work low latency? Which python jack bindings are you using? > Have you got dsp and gui process separation? I was thinking about a > DAW/midi/osc sequencer with this kind of arch, python for gui, c for > dsp stuff, process separated and communication over OSC. I had not seen LV2, and it looks very exciting and interesting. DSSI support would also be good when we get MIDI integration. In terms of latency, thats a GStreamer issue, and although it is not perfect right now, the GStreamer guys are looking into solving some syncing issues. As for Python Jack bindings, we don't use Jack, we use GStreamer. Our audio processing and GUI is very seperated. Cheers! Jono From smcameron at yahoo.com Mon Jul 17 08:24:46 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Mon Jul 17 08:24:57 2006 Subject: [linux-audio-dev] MIDI... know how to do bank/patch changes on yamaha Motif Rack? In-Reply-To: <20060717080044.GA4419@turing.informatik.uni-halle.de> Message-ID: <20060717122446.33265.qmail@web33004.mail.mud.yahoo.com> > The manual should document somewhere what the MSB value for this bank > is, but it's certainly not F3. Oops, it's 3f. Thanks for the education on the other stuff too. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mobarre at gmail.com Mon Jul 17 09:58:19 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Mon Jul 17 09:58:26 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <200607172209.34722.voidcreature@paradise.net.nz> References: <44BB5FA7.8060605@web.de> <200607172209.34722.voidcreature@paradise.net.nz> Message-ID: <3c808a150607170658m7ca221f7o31422eb54e730024@mail.gmail.com> > wow, that looks pretty good. > > i'm off to write an arts backend to feed into pulseaudio right away. so i can > have noatun->arts->pulseaudio->alsa->jack->alsa->soundcard > > i wonder if i somehow get esd into that chain somewhere too? > > because you can never have too many sound servers. Do you think there a possibility to have something like : totem->gstreamer->arts->pulseaudio->alsa->jack->alsa->soundcard->back-in-my-RME ->jack->ardour I would need this to convert a CD into wav... Sorry, I'm just being stupid ;-p -- Marc-Olivier Barre, Kinoko en Orbite. From kouhia at nic.funet.fi Mon Jul 17 12:50:43 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Mon Jul 17 12:50:55 2006 Subject: [linux-audio-dev] Re: Converting a 24bit sample to 16bit Message-ID: >From: James Courtier-Dutton > >Is there a standard way of converting a 24bit sample to 16bit? How your 24bit audio was made? If your audio card gives out 24-bit, then you may loose bits because there are no true 24-bit converters. At top you could use a smooth hard-limiter (which processes each sample separately). It takes out random high peaks and makes the audio more analogue. At bottom the dither noise may not be necessary if the audio source's noise floor is high enough. All dither tests seems to test against the mathematical sine wave which you don't get if you do acoustic music. Noiseshaping dither is suspectible as well because one may then wonder where the high frequency noise introduced by the dither goes to. No amplifier near me have a dither noise remover. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From fons.adriaensen at skynet.be Mon Jul 17 13:30:29 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Mon Jul 17 13:29:49 2006 Subject: [linux-audio-dev] Improved decoder plugins for Linux Message-ID: <20060717173029.GA5971@linux-1.site> Hello all, I just updated the small set of Ambisionics related LADSPA plugins available at . The three decoders now feature optional phase aligned shelf filters and independent control for LF and HF gain of the velocity components (from in-phase over max rE to max rV). The distance compensation is still there of course (and correctly calibrated !). -- FA Follie! Follie! Delirio vano e' questo! From loki.davison at gmail.com Wed Jul 19 23:15:59 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Jul 19 23:16:08 2006 Subject: [linux-audio-dev] Re: light C++ set for WAV In-Reply-To: <20060714073131.GB5357@login.ecs.soton.ac.uk> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <1152825361.5398.7.camel@localhost.localdomain> <20060714073131.GB5357@login.ecs.soton.ac.uk> Message-ID: On 7/14/06, Steve Harris wrote: > On Thu, Jul 13, 2006 at 05:16:01 -0400, Paul Davis wrote: > > On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote: > > > but I am not a fan nor a great user of C++. The wrapper should > > > really be written by someone with a love for the language. > > > > LOL! that's pretty great. "not a fan" translates in real world terms > > into "one of LAD's most persistent critics of almost every aspect of C+ > > +" :)) rock on erik, we love you anyway! > > Dammit, I feel insulted ;) > > Though, having just part-written a huge database engine in C I am feeling > warm thoughts about ObjectiveC, which maybe makes me a traitor to the > cause. > > Go Ocaml though. > > - Steve > There are quite a few c++ 'not fans' on LAD. C and python all the way ;) Loki From mle+la at mega-nerd.com Thu Jul 20 00:00:07 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Jul 20 00:00:19 2006 Subject: [linux-audio-dev] Re: light C++ set for WAV In-Reply-To: References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <1152825361.5398.7.camel@localhost.localdomain> <20060714073131.GB5357@login.ecs.soton.ac.uk> Message-ID: <20060720140007.d53da0be.mle+la@mega-nerd.com> Loki Davison wrote: > There are quite a few c++ 'not fans' on LAD. C and python all the way ;) I used to be a Python fan but for anything larger than a couple of hundred lines I now prefer Ocaml. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom." -- Clifford Stoll From loki.davison at gmail.com Thu Jul 20 02:57:38 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 20 02:57:47 2006 Subject: [linux-audio-dev] Re: light C++ set for WAV In-Reply-To: <20060720140007.d53da0be.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <1152825361.5398.7.camel@localhost.localdomain> <20060714073131.GB5357@login.ecs.soton.ac.uk> <20060720140007.d53da0be.mle+la@mega-nerd.com> Message-ID: On 7/20/06, Erik de Castro Lopo wrote: > Loki Davison wrote: > > > There are quite a few c++ 'not fans' on LAD. C and python all the way ;) > > I used to be a Python fan but for anything larger than a couple > of hundred lines I now prefer Ocaml. > > Erik I haven't tried ocaml. I should put it on the todo list. ;) I'm a bit of a lisper and i find it easier to find places that let me program in python than lisp/scheme, so it's a good back up plan. Jobs for both are pretty damn hard to find though. :) Loki From pcoccoli at gmail.com Thu Jul 20 09:48:24 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Thu Jul 20 09:48:35 2006 Subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV] Message-ID: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> On 7/20/06, Loki Davison wrote: > On 7/20/06, Erik de Castro Lopo wrote: > > Loki Davison wrote: > > > > > There are quite a few c++ 'not fans' on LAD. C and python all the way ;) > > > > I used to be a Python fan but for anything larger than a couple > > of hundred lines I now prefer Ocaml. > > > > Erik > > I haven't tried ocaml. I should put it on the todo list. ;) I'm a bit > of a lisper and i find it easier to find places that let me program in > python than lisp/scheme, so it's a good back up plan. Jobs for both > are pretty damn hard to find though. :) > > Loki > You pretty much can't ever ask something about C++ without all the haters coming out. I've worked professionally using only C++ (and a little plain old C) for 8 years, and the last 6 have been exclusively on Linux. Ocaml may be programming nirvana, but it likely won't pay the bills, so I won't be spending any time on it. From _ at whats-your.name Thu Jul 20 13:05:50 2006 From: _ at whats-your.name (carmen) Date: Thu Jul 20 13:05:51 2006 Subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> Message-ID: <20060720170550.GJ25098@replic.net> > I've worked professionally using only C++ (and a little plain old C) > for 8 years, and the last 6 have been exclusively on Linux. Ocaml may > be programming nirvana, but it likely won't pay the bills huh? i see job posts every week on nyc craigslist $130-150K OCaml programmers for large investment house.. if you mean OCaml && audio, probably. there only room for so many 'tenured developers' at CCRMA/CNMAT, eh.. From kouhia at nic.funet.fi Thu Jul 20 16:05:02 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Thu Jul 20 16:05:24 2006 Subject: [linux-audio-dev] Re: diskstream and jack Message-ID: >From: conrad berhrster > >Now the question: >- The worker thread is faster then the jackthread. (Sure, it should be). What >is the usual way to pause the workerthread and wake up again, when the >ringbuffer needs more data. My alsashmrec uses kill((pid_t)diskpid,SIGSTOP); (in disk writer process) and kill((pid_t)diskpid,SIGCONT); (in A/D reader process) Perhaps that could be replaced with semaphore but what if multiple processes uses the same disk service process? That increases the number of SIGCONTs but otherwise the processes would be uncoupled. How it is with semaphores? >- How should the ringbuffer be initilized when starting to play? Fill it up if its size was selected optimally. If you have multiple songs and you don't know which the user would like to play next, then make one ringbuffer per song and fill them all up. Then the playing can start instantly when user presses the song button. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From kouhia at nic.funet.fi Thu Jul 20 16:05:04 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Thu Jul 20 16:05:38 2006 Subject: [linux-audio-dev] Re: Nomad - Nord Modular Editor Message-ID: [ in linux-audio-users, originally in nmedit-devel ] >our first release of Nomad - Nord Modular Editor is now available. It is at http://nmedit.sourceforge.net if that was not mentioned. The Nomad has also a UI builder for building UIs for modules. Check the screenshots and "nomad-ui-editor.jpg". Do we have anything similar? E.g. a collection of audio related widgets for Glade? How Nomad's UI builder could be re-used in other projects? By using it like VSTGUI? By building module UIs for Csound opcodes and writing Csound exporter? I have earlier suggested that Nord Modular modules could be written as Csound instruments, i.e., Nomad + Exporter + Csound == NM clone. One may find several thousands of NM patches from the web. Many of them are advanced and well documented. http://nm-archives.electro-music.com/010_NordModular/014_Interesting_Threads/ Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From mle+la at mega-nerd.com Thu Jul 20 17:05:47 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Jul 20 17:05:57 2006 Subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> Message-ID: <20060721070547.1e32d304.mle+la@mega-nerd.com> Paul Coccoli wrote: > You pretty much can't ever ask something about C++ without all the > haters coming out. C++ has more big ugly warts that any other language I can think of. > I've worked professionally using only C++ (and a little plain old C) > for 8 years, and the last 6 have been exclusively on Linux. Ocaml may > be programming nirvana, but it likely won't pay the bills, I'm currently using Ocaml at work, but I also do C, C++, C#, Python Actionscript and Verilog. I also have a friend who is doing a whole bunch of distributed processing using Erlang, a language which is on my "to learn" list. I'm not so much a specific language fanboy as a languages fanboy. There are so many languages out there that are outside the C, C++, Java and C# bucket that offer features that people in the C/C++/Java/C# camp don't even know about. > so I won't be spending any time on it. Thats your choice, but 6 months learning Ocaml taught me more about programming than I learned in the previous 5 years of a 10 plus year programming career. Being open to new tools, languages and techniques means that my employer now considers me the guy who can be relied on to fix anything that is actually fixable, regardless of whether I've used it before. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Java sucks. C sucks slightly less so, but only because it makes no pretense at all about being a high level language. From radarsat1 at gmail.com Thu Jul 20 19:05:36 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jul 20 19:22:43 2006 Subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060721070547.1e32d304.mle+la@mega-nerd.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> Message-ID: <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> > I'm not so much a specific language fanboy as a languages fanboy. > There are so many languages out there that are outside the C, C++, > Java and C# bucket that offer features that people in the > C/C++/Java/C# camp don't even know about. I agree... Programming languages are amazing tools... just as natural languages affects how we think, programming languages affect how we code. However, to bring this conversation back to a thread from a few weeks ago, I find it interesting, and sometimes frustrating, that most new languages that differ from C/C++ tend to target interpreters and virtual machines. Does anyone know any interesting and powerful languages that can be used just like C? That can link to C libraries, and can be compiled to native machine code, and can express the same low-level concepts as C, but in a more powerful and intuitive way? In short, does anyone know any languages other than C and C++ that would be interesting for audio programming? This list has made of aware of FAUST and some other interesting examples of "meta-languages" that compile to C code. I do find this interesting, but I would like a more common ground: something that can be used in a more general-purpose way (like C), but is still useful for audio, realtime programming, and maybe even operating systems (like C). I'm not one to argue against C or C++ actually, but having experienced Python and other high-level languages, I find myself wanting to use such a syntax for natively compiled code. I suppose that one could argue that a lot of the power of these interpreted languages comes from the fact that they are often dynamically and loosely typed, which is much more difficult to express in optimized, compiled code. It's precisely the strong typing and well-defined memory usage that makes C useful for things like operating systems and realtime programming. I do understand that. I am only suggesting that maybe there is some middle-ground between the likes of C and Python, that happens to not be C++. Anyone? I have often wondered what I might do if I tried to design such a language, but I think it's just too big a task. (For now anyways.) And I would hate to re-invent the wheel yet again. Steve From loki.davison at gmail.com Thu Jul 20 19:39:03 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 20 19:39:11 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> Message-ID: On 7/21/06, Stephen Sinclair wrote: > > I'm not so much a specific language fanboy as a languages fanboy. > > There are so many languages out there that are outside the C, C++, > > Java and C# bucket that offer features that people in the > > C/C++/Java/C# camp don't even know about. > > > I agree... Programming languages are amazing tools... just as natural > languages affects how we think, programming languages affect how we > code. > > However, to bring this conversation back to a thread from a few weeks > ago, I find it interesting, and sometimes frustrating, that most new > languages that differ from C/C++ tend to target interpreters and > virtual machines. > > Does anyone know any interesting and powerful languages that can be > used just like C? That can link to C libraries, and can be compiled to > native machine code, and can express the same low-level concepts as C, > but in a more powerful and intuitive way? In short, does anyone know > any languages other than C and C++ that would be interesting for audio > programming? > > This list has made of aware of FAUST and some other interesting > examples of "meta-languages" that compile to C code. I do find this > interesting, but I would like a more common ground: something that can > be used in a more general-purpose way (like C), but is still useful > for audio, realtime programming, and maybe even operating systems > (like C). > > I'm not one to argue against C or C++ actually, but having experienced > Python and other high-level languages, I find myself wanting to use > such a syntax for natively compiled code. > > I suppose that one could argue that a lot of the power of these > interpreted languages comes from the fact that they are often > dynamically and loosely typed, which is much more difficult to express > in optimized, compiled code. It's precisely the strong typing and > well-defined memory usage that makes C useful for things like > operating systems and realtime programming. I do understand that. I am > only suggesting that maybe there is some middle-ground between the > likes of C and Python, that happens to not be C++. Anyone? > > I have often wondered what I might do if I tried to design such a > language, but I think it's just too big a task. (For now anyways.) > And I would hate to re-invent the wheel yet again. > > > Steve For music/audio stuff you can do the dsp stuff with c and then communicate with another process written in a higher level language, i.e python over OSC. The LAD irc crew have been discussing using this idea for a new sequencer/daw thing. Loki From james at dis-dot-dat.net Thu Jul 20 20:13:43 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Thu Jul 20 20:13:49 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> Message-ID: <20060721001343.GZ9439@fitz.Belkin> On Fri, 21 Jul, 2006 at 09:39AM +1000, Loki Davison spake thus: > On 7/21/06, Stephen Sinclair wrote: ... > For music/audio stuff you can do the dsp stuff with c and then > communicate with another process written in a higher level language, > i.e python over OSC. The LAD irc crew have been discussing using this > idea for a new sequencer/daw thing. And I've been doing it with a small sample player. It works nicely and means I don't have to deal with UI crud in C (nightmare!). James > Loki > From seablaede at gmail.com Thu Jul 20 23:22:45 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Jul 20 22:18:35 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> Message-ID: <44C04885.4020801@gmail.com> >> > > For music/audio stuff you can do the dsp stuff with c and then > communicate with another process written in a higher level language, > i.e python over OSC. The LAD irc crew have been discussing using this > idea for a new sequencer/daw thing. Hmm this is interesting as I have been considering doing something similar as well. I was wondering how much of a difference having a GUI built in a non realtime style, either in an interpreted language or similar setup, how this might affect things for audio use. I was considering using OSC style communication between a backend written in C/C++ and a GUI written in a seperate language. Seablade From loki.davison at gmail.com Thu Jul 20 23:31:17 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 20 23:31:25 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <44C04885.4020801@gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> Message-ID: On 7/21/06, Thomas Vecchione wrote: > >> > > > > For music/audio stuff you can do the dsp stuff with c and then > > communicate with another process written in a higher level language, > > i.e python over OSC. The LAD irc crew have been discussing using this > > idea for a new sequencer/daw thing. > > Hmm this is interesting as I have been considering doing something > similar as well. I was wondering how much of a difference having a GUI > built in a non realtime style, either in an interpreted language or > similar setup, how this might affect things for audio use. > > I was considering using OSC style communication between a backend > written in C/C++ and a GUI written in a seperate language. > > Seablade ??? Non realtime style? How can you have a gui written in a real time style? Doesn't that kind of break the basic rules of realtime? Loki From seablaede at gmail.com Fri Jul 21 00:51:05 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Jul 20 23:46:32 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> Message-ID: <44C05D39.1070306@gmail.com> > > ??? Non realtime style? How can you have a gui written in a real time > style? Doesn't that kind of break the basic rules of realtime? Well that is my question, sorry I should have clarified I am just now getting into realtime programming so this might be a really stupid question anyways. If you dont have the GUI thread(s) running at a high priority, would that affect the overall response of the program? Primarily I am looking at for triggering sound effects samples(Of varying size) for live performance, thus I would need to make sure response to the gui is also quick and that latency is not added in from the time of hitting a "go" on screen. Of course it might be very possible I am misunderstanding basic principles behind realtime programming at any rate so please feel free to just tell me Im stupid;) Seablade From S.W.Harris at ecs.soton.ac.uk Fri Jul 21 03:38:38 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Jul 21 03:39:00 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060721001343.GZ9439@fitz.Belkin> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <20060721001343.GZ9439@fitz.Belkin> Message-ID: <20060721073838.GA20890@login.ecs.soton.ac.uk> On Fri, Jul 21, 2006 at 01:13:43 +0100, james@dis-dot-dat.net wrote: > On Fri, 21 Jul, 2006 at 09:39AM +1000, Loki Davison spake thus: > > On 7/21/06, Stephen Sinclair wrote: > ... > > For music/audio stuff you can do the dsp stuff with c and then > > communicate with another process written in a higher level language, > > i.e python over OSC. The LAD irc crew have been discussing using this > > idea for a new sequencer/daw thing. > > And I've been doing it with a small sample player. It works nicely > and means I don't have to deal with UI crud in C (nightmare!). SooperLooper (http://essej.net/sooperlooper/) works that way and has done for some time. Some added bonuses are that your backend is inherantly scriptable from other environments, and it pretty much forces you to adopt a MVC UI coding model. - Steve From S.W.Harris at ecs.soton.ac.uk Fri Jul 21 03:52:42 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Jul 21 03:53:06 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <44C05D39.1070306@gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> <44C05D39.1070306@gmail.com> Message-ID: <20060721075242.GB20890@login.ecs.soton.ac.uk> On Thu, Jul 20, 2006 at 09:51:05 -0700, Thomas Vecchione wrote: > > > >??? Non realtime style? How can you have a gui written in a real time > >style? Doesn't that kind of break the basic rules of realtime? > > Well that is my question, sorry I should have clarified I am just now > getting into realtime programming so this might be a really stupid > question anyways. If you dont have the GUI thread(s) running at a high > priority, would that affect the overall response of the program? > Primarily I am looking at for triggering sound effects samples(Of > varying size) for live performance, thus I would need to make sure > response to the gui is also quick and that latency is not added in from > the time of hitting a "go" on screen. The extent of that kind of latency is not quite so critical as processing latency. What is important however is that the latency is constant, jitter is quite obvious. Humans are able to correct for reasonably high constant latency between actions and the sound happening. MIDI latency is typically 1ms or so, and that's generally not a issue. Getting lower than that in a UI + OSC connection is no problem. In any case, it's not a good idea to run GUI theads at high priority as they often have to do actions which require a significant ammount of wall-clock time. If your thinking of using a UDPish protocol, please use OSC. The packet format is a bit of a pig, but there are plenty of libraries that make it easy (eg. http://liblo.sourceforge.net/) it means other peoples software can interoperate with yours. It will also save you a lot of time in debugging annoying network I/O issues and platform dependencies. - Steve From Dr.Graef at t-online.de Fri Jul 21 05:50:33 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri Jul 21 05:38:55 2006 Subject: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> Message-ID: <44C0A369.30803@t-online.de> Stephen Sinclair wrote: > Does anyone know any interesting and powerful languages that can be > used just like C? That can link to C libraries, and can be compiled to > native machine code, and can express the same low-level concepts as C, > but in a more powerful and intuitive way? In short, does anyone know > any languages other than C and C++ that would be interesting for audio > programming? As SuperCollider and ChucK show, being interpreted and dynamically typed doesn't preclude lowlat realtime audio work. I'd also like to mention my own brainchild Q (http://q-lang.sf.net), a general-purpose functional programming language which interfaces nicely to MidiShare, Faust and (via OSC) SuperCollider and is certainly usable for doing soft realtime stuff for audio and computer music applications. > I have often wondered what I might do if I tried to design such a > language, but I think it's just too big a task. You can bet on that. :) Faust, ChucK and SuperCollider are all domain-specific languages which makes the task somewhat simpler. There's no doubt that creating a very-high-level language, which supports *both* lowlat signal processing and general-purpose programming equally well, will be a major undertaking which still needs a considerable amount of research. One might argue that modern-style FPLs like Ocaml and Haskell are almost there, but AFAICS they still lack realtime-capable multithreading and decent multimedia interfaces. And we need more brave souls like Erik who are willing to stray away from the traditional paths and give those new languages a chance. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From eric at zhevny.com Fri Jul 21 11:08:21 2006 From: eric at zhevny.com (Eric Dantan Rzewnicki) Date: Fri Jul 21 11:08:31 2006 Subject: [linux-audio-dev] [ANN] New specimen list and home Message-ID: <20060721150821.GO2864@zhevny.com> Hello all, I've set up a mailing list for specimen: http://zhevny.com/mailman/listinfo/specimen Additionally the web site now lives at http://zhevny.com/specimen. This is a minimal re-working of Pete's old site. More improvements to follow. Let me know if anything is badly broken. (I know the guide is broken, but I need to re-do it with new screenshots anyway.) I just changed the dns record for zhevny.com to point to a new host earlier today. The TTL was set to 1 day, so some of you may get pointed to the old box. Let me know if you have any issues, or just try again a little later. Thanks, Eric Rz. From seablaede at gmail.com Fri Jul 21 15:32:08 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Fri Jul 21 14:28:21 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060721075242.GB20890@login.ecs.soton.ac.uk> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> <44C05D39.1070306@gmail.com> <20060721075242.GB20890@login.ecs.soton.ac.uk> Message-ID: <44C12BB8.9060502@gmail.com> > What is important however is that the latency is constant, jitter > is quite obvious. Makes sense, how often is jitter in that regards a problem and if it is a decent amount of time, what might be done to help with that problem? > MIDI latency is typically > 1ms or so, and that's generally not a issue. Yea a ms or less definitely wouldn't be a problem for what I am thinking of. I tend to think slightly higher might not be a problem either, but I was worried it might get over, say 3 mS which I think might cause a problem. This is overall between GUI and communication. > Getting lower than that in > a UI + OSC connection is no problem. That is good to know and exactly answers my question I think, thanks. > In any case, it's not a good idea to run GUI theads at high priority as > they often have to do actions which require a significant ammount of > wall-clock time. Again thanks for the information. > If your thinking of using a UDPish protocol, please use OSC. Was definitely considering it. I suppose my question there might be, while I don't have intentions for it currently, I don't want to rule out the possibility of the FE running on a separate machine, and I would be worried about packet loss with UDP over a network or possibly wireless connection (Not looking for wireless for show conditions, more for say in a theater show when I might be setting cue levels by running a FE on my PDA). But yes OSC is definitely looking like a good possibility. Of course I haven't looked to see if there is an OSC lib for my PDA much less most PDAs;) Seablade From rlrevell at joe-job.com Fri Jul 21 16:48:11 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jul 21 16:47:49 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <44BB5FA7.8060605@web.de> References: <44BB5FA7.8060605@web.de> Message-ID: <1153514891.17115.24.camel@mindpipe> On Mon, 2006-07-17 at 12:00 +0200, Jan Weil wrote: > Apparently, a Sound BOF took place at GUADEC 2006 > . Slides that were presented: > > > It seems that PulseAudio , formerly known as > Polypaudio, could be (is?) GNOME's new audio server of choice replacing esd. Great. One of the bullet points on the "Future directions" slide is "Professional audio?". So it was not designed for professional use from the ground up. If Apple can design a single sound system that's usable for desktop toys AND pro audio why can't we? Lee From fbar at footils.org Fri Jul 21 17:01:23 2006 From: fbar at footils.org (Frank Barknecht) Date: Fri Jul 21 17:01:45 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <44C12BB8.9060502@gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> <44C05D39.1070306@gmail.com> <20060721075242.GB20890@login.ecs.soton.ac.uk> <44C12BB8.9060502@gmail.com> Message-ID: <20060721210123.GO11973@fliwatut.scifi> Hallo, Thomas Vecchione hat gesagt: // Thomas Vecchione wrote: > my PDA). But yes OSC is definitely looking like a good possibility. Of > course I haven't looked to see if there is an OSC lib for my PDA much > less most PDAs;) liblo runs on PDAs. Check out the asciimatrix by Martin Rumori and Andreas Krach, for example their presentation at the Linux AUdio Conference this year. asciimatrix uses liblo. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From _ at whats-your.name Fri Jul 21 17:05:33 2006 From: _ at whats-your.name (carmen) Date: Fri Jul 21 17:05:33 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <1153514891.17115.24.camel@mindpipe> References: <44BB5FA7.8060605@web.de> <1153514891.17115.24.camel@mindpipe> Message-ID: <20060721210533.GA29524@replic.net> > Great. One of the bullet points on the "Future directions" slide is > "Professional audio?". So it was not designed for professional use from > the ground up. > > If Apple can design a single sound system that's usable for desktop toys > AND pro audio why can't we? kde4 will be using 'phonon', an additional layer of abstraction on top of gstreamer. if you hold your breath and wake up in 3 years maybe gstreamer wil even have a working JACK sink (). i cant imagine any desktop distribution going with such a rube goldberg contraption though.. from what i can tell, pulseaudio mainly offers better resampling/softmixing than dmix, and the ability to connect to win32's soundsystem in addition to ALSA, in the spirit of pa18(or is that 19).. i really think the developers of phonon, pulseaudio, gstreamer, portaudio, jack, alsa, and oss-free need to get together, eat some LSD or drink some coffee, tea, or whatever, and not leave the room until they work their shit out. in the meantime i'll accept the fact that i cant answer VOIP calls if any other soundapp is running..if its important, they can email ;) > > Lee > From ce at christeck.de Fri Jul 21 17:11:31 2006 From: ce at christeck.de (Christoph Eckert) Date: Fri Jul 21 17:13:01 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <1153514891.17115.24.camel@mindpipe> References: <44BB5FA7.8060605@web.de> <1153514891.17115.24.camel@mindpipe> Message-ID: <200607212311.31970.ce@christeck.de> > If Apple can design a single sound system that's usable for desktop > toys AND pro audio why can't we? sigh :) . Cheers, ce From drobilla at connect.carleton.ca Fri Jul 21 17:29:13 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Jul 21 17:29:26 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <44C12BB8.9060502@gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> <44C05D39.1070306@gmail.com> <20060721075242.GB20890@login.ecs.soton.ac.uk> <44C12BB8.9060502@gmail.com> Message-ID: <1153517353.14939.3.camel@localhost.localdomain> On Fri, 2006-07-21 at 12:32 -0700, Thomas Vecchione wrote: > > If your thinking of using a UDPish protocol, please use OSC. > > Was definitely considering it. I suppose my question there might be, > while I don't have intentions for it currently, I don't want to rule out > the possibility of the FE running on a separate machine, and I would be > worried about packet loss with UDP over a network or possibly wireless > connection (Not looking for wireless for show conditions, more for say > in a theater show when I might be setting cue levels by running a FE on > my PDA). But yes OSC is definitely looking like a good possibility. Of > course I haven't looked to see if there is an OSC lib for my PDA much > less most PDAs;) OSC can go over TCP to avoid the packet loss issue (and messed up ordering which can be extremely annoying as well). liblo's TCP support needs some work though. -DR- From drobilla at connect.carleton.ca Sat Jul 22 01:56:47 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 22 01:56:54 2006 Subject: [linux-audio-dev] FYI: GUADEC 2006 Sound BOF In-Reply-To: <1153514891.17115.24.camel@mindpipe> References: <44BB5FA7.8060605@web.de> <1153514891.17115.24.camel@mindpipe> Message-ID: <1153547807.23663.3.camel@localhost.localdomain> On Fri, 2006-07-21 at 16:48 -0400, Lee Revell wrote: > On Mon, 2006-07-17 at 12:00 +0200, Jan Weil wrote: > > Apparently, a Sound BOF took place at GUADEC 2006 > > . Slides that were presented: > > > > > > It seems that PulseAudio , formerly known as > > Polypaudio, could be (is?) GNOME's new audio server of choice replacing esd. > > Great. One of the bullet points on the "Future directions" slide is > "Professional audio?". So it was not designed for professional use from > the ground up. > > If Apple can design a single sound system that's usable for desktop toys > AND pro audio why can't we? Because all the decrepit die-hard Unix people refuse to admit (or are too audio-ignorant to know) that the good ol' blocking read/write model that works so nicely for text is just plain crap for audio? -DR- From lazzaro at eecs.berkeley.edu Sat Jul 22 13:40:14 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Sat Jul 22 13:40:24 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060722055700.6B5DE23D15B0@music.columbia.edu> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> Message-ID: <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> > Dave Robillard wrote: > > OSC can go over TCP to avoid the packet loss issue (and messed up > ordering which can be extremely annoying as well). liblo's TCP > support > needs some work though. This comment illustrates an advantage for using RTP MIDI to send MIDI over lossy networks. The recovery journal in RTP MIDI supports graceful recovery from the loss of an arbitrary number of packets upon the receipt of the first packet after the loss (also works for reordering). Journalling is a feed-forward process, no retransmission is used -- thus, no head-of-line-blocking latency issues as one has when running media over TCP. See: http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html The IESG approved RTP MIDI in February, so the protocol is frozen. Hopefully the copy-edit phase will be done by autumn and then we'll have RFC numbers for RTP MIDI. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From loki.davison at gmail.com Sat Jul 22 21:52:58 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sat Jul 22 21:53:10 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> Message-ID: On 7/23/06, lazzaro wrote: > > > Dave Robillard wrote: > > > > OSC can go over TCP to avoid the packet loss issue (and messed up > > ordering which can be extremely annoying as well). liblo's TCP > > support > > needs some work though. > > > This comment illustrates an advantage for using RTP MIDI > to send MIDI over lossy networks. The recovery journal in > RTP MIDI supports graceful recovery from the loss of an arbitrary > number of packets upon the receipt of the first packet after the > loss (also works for reordering). Journalling is a feed-forward > process, > no retransmission is used -- thus, no head-of-line-blocking latency > issues as one has when running media over TCP. > > See: > > http://www.cs.berkeley.edu/~lazzaro/rtpmidi/index.html > > The IESG approved RTP MIDI in February, so the protocol is > frozen. Hopefully the copy-edit phase will be done by autumn > and then we'll have RFC numbers for RTP MIDI. > > --- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro > lazzaro [at] cs [dot] berkeley [dot] edu > --- Yay! i want my whole app to communicate between engine and gui via midi! That's going to really be interesting... So what CC would i use for add a new node named "node"? Sysex i guess? .... Loki From drobilla at connect.carleton.ca Sat Jul 22 23:15:25 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Jul 22 23:15:39 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> Message-ID: <1153624525.26648.8.camel@localhost.localdomain> On Sat, 2006-07-22 at 10:40 -0700, lazzaro wrote: > > Dave Robillard wrote: > > > > OSC can go over TCP to avoid the packet loss issue (and messed up > > ordering which can be extremely annoying as well). liblo's TCP > > support > > needs some work though. > > > This comment illustrates an advantage for using RTP MIDI > to send MIDI over lossy networks. The recovery journal in > RTP MIDI supports graceful recovery from the loss of an arbitrary > number of packets upon the receipt of the first packet after the > loss (also works for reordering). Journalling is a feed-forward > process, > no retransmission is used -- thus, no head-of-line-blocking latency > issues as one has when running media over TCP. Sure, for MIDI. MIDI has a lot of built-in semantics you can use to accomplish things like this, but OSC doesn't. As Loki pointed out, MIDI is no OSC (eg it sucks) :) You could do it on a per-app basis (since you actually know something about the information being transmitted), but a parallel to RTP MIDI can't really be done for OSC (TCP isn't the only solution though, it just happens to be what's around and obvious to use. You can wrap OSC in pretty much anything (and still be totally conformant)) I don't see it as much of a problem anyway. At least in all my use cases, there's realtime crucial data (eg what MIDI tends to do, controllers, notes, etc) and there's data that just needs to get there sanely. The nice thing about the realtime stuff is that lost messages don't really matter, all you care about is the most recent one anyway. I need to do a bit of work on liblo to get TCP working better, but I'm just going to use UDP for the former (realtime) and TCP for the latter (reliable). (On the local machine there's more fun possibilities like a POSIX message queue backend for liblo or similar, but that's an aside I'm just curious about at the moment) -DR- From jens.andreasen at chello.se Sun Jul 23 04:27:40 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Jul 23 04:58:22 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> Message-ID: <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote: > Yay! i want my whole app to communicate between engine and gui via > midi! That's going to really be interesting... So what CC would i use > for add a new node named "node"? Sysex i guess? .... CC 0x06 (Data Entry) would be a good candidate for entering text, possibly with 0x96, 0x97 (data increment, decrement) to be used as a cursor. The backend will "know" that you are setting the text field of a node because you immediately before have send a Non-Registered Pararameter Number (CC 0x98 MSB, 0x99 LSB), setting the mode or destination to whatever you have found reasonable to represent "node-name". Problems: Attempts at midi-merge may fail. The data-entry slider cannot be connected to two separate destinations simultaniously in any meaningful way, other than that the last connection wins and all of the data goes there. > Loki -- From loki.davison at gmail.com Sun Jul 23 05:36:45 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Jul 23 05:36:58 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: On 7/23/06, Jens M Andreasen wrote: > On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote: > > > Yay! i want my whole app to communicate between engine and gui via > > midi! That's going to really be interesting... So what CC would i use > > for add a new node named "node"? Sysex i guess? .... > > CC 0x06 (Data Entry) would be a good candidate for entering text, > possibly with 0x96, 0x97 (data increment, decrement) to be used as a > cursor. > > The backend will "know" that you are setting the text field of a node > because you immediately before have send a Non-Registered Pararameter > Number (CC 0x98 MSB, 0x99 LSB), setting the mode or destination to > whatever you have found reasonable to represent "node-name". > > Problems: Attempts at midi-merge may fail. The data-entry slider cannot > be connected to two separate destinations simultaniously in any > meaningful way, other than that the last connection wins and all of the > data goes there. > > > Loki > -- minor downside is that it sounds horrible and complicated and like you've escaped to the 80's. Yay back to the future... You just can't say in midi "set the sine osc to 440 hz." I.e you can say in your message that you are setting a oscillator called something. You can in osc, so much more human readable. Loki From jens.andreasen at chello.se Sun Jul 23 07:41:02 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Jul 23 07:41:11 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> On Sun, 2006-07-23 at 19:36 +1000, Loki Davison wrote: > On 7/23/06, Jens M Andreasen wrote: > > On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote: > > > > > Yay! i want my whole app to communicate between engine and gui via > > > midi! That's going to really be interesting... So what CC would i use > > > for add a new node named "node"? Sysex i guess? .... > > > > CC 06 (Data Entry) would be a good candidate for entering text, > > possibly with 96, 97 (data increment, decrement) to be used as a > > cursor. > > > > The backend will "know" that you are setting the text field of a node > > because you immediately before have send a Non-Registered Pararameter > > Number (CC 98 MSB, 99 LSB), setting the mode or destination to > > whatever you have found reasonable to represent "node-name". > > > > Problems: Attempts at midi-merge may fail. The data-entry slider cannot > > be connected to two separate destinations simultaniously in any > > meaningful way, other than that the last connection wins and all of the > > data goes there. > > > > > Loki > > -- > > minor downside is that it sounds horrible and complicated and like > you've escaped to the 80's. Yay back to the future... You just can't > say in midi "set the sine osc to 440 hz." I.e you can say in your > message that you are setting a oscillator called something. You can in > osc, so much more human readable. > The implementation could be a switch on the current NRPN. Nothing complicated or unusual here. Or with a bit of carefulness, you could also do an array of dynamically allocated function pointers The upside is that we can actually have (and I do have) a physical rotary knob that sets an oscillator to, say 440Hz. As for human readability of the message, I couldn't care less since I am not going to read the datastream aloud to myself anyway. To get text representations of unique NPRN's for readability in your sources, you would typically use something like: -- myNRPN.h --------------- #define NODE_NAME __LINE__ #define OSC_FREQ __LINE__ ... which is of course an old-fashioned technique known since the beginning of the UNIX epoch. But it still works as intended. > Loki -- From seablaede at gmail.com Sun Jul 23 16:49:45 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sun Jul 23 15:45:14 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153624525.26648.8.camel@localhost.localdomain> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153624525.26648.8.camel@localhost.localdomain> Message-ID: <44C3E0E9.1000906@gmail.com> > The nice thing about the realtime stuff is that lost messages > don't really matter, all you care about is the most recent one anyway. > Yes but out of order messages can be a real problem. Seablade From drobilla at connect.carleton.ca Sun Jul 23 17:06:12 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jul 23 17:06:26 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153688772.32381.0.camel@localhost.localdomain> On Sun, 2006-07-23 at 13:41 +0200, Jens M Andreasen wrote: > On Sun, 2006-07-23 at 19:36 +1000, Loki Davison wrote: > > On 7/23/06, Jens M Andreasen wrote: > > > On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote: > > > > > > > Yay! i want my whole app to communicate between engine and gui via > > > > midi! That's going to really be interesting... So what CC would i use > > > > for add a new node named "node"? Sysex i guess? .... > > > > > > CC 06 (Data Entry) would be a good candidate for entering text, > > > possibly with 96, 97 (data increment, decrement) to be used as a > > > cursor. > > > > > > The backend will "know" that you are setting the text field of a node > > > because you immediately before have send a Non-Registered Pararameter > > > Number (CC 98 MSB, 99 LSB), setting the mode or destination to > > > whatever you have found reasonable to represent "node-name". > > > > > > Problems: Attempts at midi-merge may fail. The data-entry slider cannot > > > be connected to two separate destinations simultaniously in any > > > meaningful way, other than that the last connection wins and all of the > > > data goes there. > > > > > > > Loki > > > -- > > > > minor downside is that it sounds horrible and complicated and like > > you've escaped to the 80's. Yay back to the future... You just can't > > say in midi "set the sine osc to 440 hz." I.e you can say in your > > message that you are setting a oscillator called something. You can in > > osc, so much more human readable. > > > > The implementation could be a switch on the current NRPN. Nothing > complicated or unusual here. Or with a bit of carefulness, you could > also do an array of dynamically allocated function pointers > > The upside is that we can actually have (and I do have) a physical > rotary knob that sets an oscillator to, say 440Hz. As for human > readability of the message, I couldn't care less since I am not going > to read the datastream aloud to myself anyway. > > To get text representations of unique NPRN's for readability in your > sources, you would typically use something like: > > -- myNRPN.h --------------- > #define NODE_NAME __LINE__ > #define OSC_FREQ __LINE__ ... Now I know what the topic of my next nightmare is going to be :) -DR- From loki.davison at gmail.com Sun Jul 23 19:14:36 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Jul 23 19:14:47 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153688772.32381.0.camel@localhost.localdomain> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> <1153688772.32381.0.camel@localhost.localdomain> Message-ID: On 7/24/06, Dave Robillard wrote: > On Sun, 2006-07-23 at 13:41 +0200, Jens M Andreasen wrote: > > On Sun, 2006-07-23 at 19:36 +1000, Loki Davison wrote: > > > On 7/23/06, Jens M Andreasen wrote: > > > > On Sun, 2006-07-23 at 11:52 +1000, Loki Davison wrote: > > > > > > > > > Yay! i want my whole app to communicate between engine and gui via > > > > > midi! That's going to really be interesting... So what CC would i > use > > > > > for add a new node named "node"? Sysex i guess? .... > > > > > > > > CC 06 (Data Entry) would be a good candidate for entering text, > > > > possibly with 96, 97 (data increment, decrement) to be used as a > > > > cursor. > > > > > > > > The backend will "know" that you are setting the text field of a node > > > > because you immediately before have send a Non-Registered Pararameter > > > > Number (CC 98 MSB, 99 LSB), setting the mode or destination to > > > > whatever you have found reasonable to represent "node-name". > > > > > > > > Problems: Attempts at midi-merge may fail. The data-entry slider > cannot > > > > be connected to two separate destinations simultaniously in any > > > > meaningful way, other than that the last connection wins and all of > the > > > > data goes there. > > > > > > > > > Loki > > > > -- > > > > > > minor downside is that it sounds horrible and complicated and like > > > you've escaped to the 80's. Yay back to the future... You just can't > > > say in midi "set the sine osc to 440 hz." I.e you can say in your > > > message that you are setting a oscillator called something. You can in > > > osc, so much more human readable. > > > > > > > The implementation could be a switch on the current NRPN. Nothing > > complicated or unusual here. Or with a bit of carefulness, you could > > also do an array of dynamically allocated function pointers > > > > The upside is that we can actually have (and I do have) a physical > > rotary knob that sets an oscillator to, say 440Hz. As for human > > readability of the message, I couldn't care less since I am not going > > to read the datastream aloud to myself anyway. > > > > To get text representations of unique NPRN's for readability in your > > sources, you would typically use something like: > > > > -- myNRPN.h --------------- > > #define NODE_NAME __LINE__ > > #define OSC_FREQ __LINE__ > > ... Now I know what the topic of my next nightmare is going to be :) > > -DR- > same... i know deep down Jens you are actually an intelligent guy from your other posts, but you really must think in a very different way to me. This looks really, really horrible compared to osc and fantastically inflexible. Especially for the original goal of this thread, engine and gui process separation... communicating between engine and gui in midi just doesn't seem nice... Loki From lazzaro at eecs.berkeley.edu Sun Jul 23 19:27:47 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Sun Jul 23 19:27:56 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060723210629.97503241E125@music.columbia.edu> References: <20060723210629.97503241E125@music.columbia.edu> Message-ID: On Jul 23, 2006, at 2:06 PM, Dave Robillard wrote: > I don't see it as much of a problem anyway. At least in all my use > cases, there's realtime crucial data (eg what MIDI tends to do, > controllers, notes, etc) and there's data that just needs to get there > sanely. The nice thing about the realtime stuff is that lost messages > don't really matter, all you care about is the most recent one anyway. Well, consider a volume slider on a mixing console. One way to send its state is to sample its value and send a packet every millisecond. In this case, your "nice thing" is true -- the occasional burst of lost or reordered packets will only cause brief "transient" artifacts. The price paid for this "nice thing" is sending 1000 packets per second, every second of the performance. The more efficient way to send the slide state is to only send packets when a human finger moves the slider. In this case, your "nice thing" is not true -- the slider might be moved by the human once per minute, and if the packet coding that move is lost, that lost packet matters for the entire minute. RTP MIDI's recovery journal lets you safely use this incremental update approach over a lossy packet stream in an efficient way ... if you need to send data over lossy networks and that fits MIDI's semantics, and TCP's head-of-line blocking latency is not acceptable, I think RTP MIDI is the right protocol to use. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From _ at whats-your.name Sun Jul 23 19:39:56 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 23 19:39:59 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> <1153688772.32381.0.camel@localhost.localdomain> Message-ID: <20060723233956.GC4735@replic.net> > same... i know deep down Jens you are actually an intelligent guy from > your other posts, but you really must think in a very different way to > me. This looks really, really horrible compared to osc and > fantastically inflexible. i thought this Port Nodes inside Sysex inside MIDI inside RTP-MIDI over TCP was a sarcastic joke. i guess everyone reads the same text differently :) From _ at whats-your.name Sun Jul 23 19:41:46 2006 From: _ at whats-your.name (carmen) Date: Sun Jul 23 19:41:59 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060723210629.97503241E125@music.columbia.edu> Message-ID: <20060723234146.GD4735@replic.net> > you need to send data over lossy networks > and that fits MIDI's semantics, and TCP's > head-of-line blocking latency is not acceptable, what sort of latency is this? ~10 ms? couldnt adjusting the MTU or something else alleviate it without having to invent "UDP + Parity Checking" ? From jens.andreasen at chello.se Sun Jul 23 21:44:26 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Jul 23 21:44:45 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> <1153688772.32381.0.camel@localhost.localdomain> Message-ID: <1153705474.9274.708.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-07-24 at 09:14 +1000, Loki Davison wrote: > > ... Now I know what the topic of my next nightmare is going to be :) > > > > -DR- > > > > same... i know deep down Jens you are actually an intelligent guy from > your other posts, but you really must think in a very different way to > me. This looks really, really horrible compared to osc and > fantastically inflexible. Especially for the original goal of this > thread, engine and gui process separation... communicating between > engine and gui in midi just doesn't seem nice... > The thing here is that I prefer to use external knobs rather than widgets on a screen. The only way to communicate in a way that works across boundaries is midi. As for flexibility. If we stick to the NRPN's for a moment, we could think of them as a huge switch-board with 127*127 destinations (msb*lsb) each capable of holding a 14bit value. Their meaning is what we want or need them to be. To me this seems like a flexible enough starting point. As for applying meaning to bit-patterns, that would depend on the application. My own variables comes in multiples of 8 or 4 so that helps in remembering what and where they are. > Loki -- From drobilla at connect.carleton.ca Mon Jul 24 03:27:19 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jul 24 03:27:29 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060723210629.97503241E125@music.columbia.edu> Message-ID: <1153726039.683.36.camel@localhost.localdomain> On Sun, 2006-07-23 at 16:27 -0700, lazzaro wrote: > On Jul 23, 2006, at 2:06 PM, Dave Robillard > wrote: > > > I don't see it as much of a problem anyway. At least in all my use > > cases, there's realtime crucial data (eg what MIDI tends to do, > > controllers, notes, etc) and there's data that just needs to get there > > sanely. The nice thing about the realtime stuff is that lost messages > > don't really matter, all you care about is the most recent one anyway. > > > Well, consider a volume slider on a mixing console. > > One way to send its state is to sample its value and > send a packet every millisecond. In this case, your > "nice thing" is true -- the occasional burst of lost > or reordered packets will only cause brief "transient" > artifacts. The price paid for this "nice thing" is > sending 1000 packets per second, every second > of the performance. > > The more efficient way to send the slide state > is to only send packets when a human finger > moves the slider. In this case, your "nice thing" > is not true -- the slider might be moved by the > human once per minute, and if the packet coding > that move is lost, that lost packet matters for the > entire minute. > > RTP MIDI's recovery journal lets you safely use > this incremental update approach over a lossy > packet stream in an efficient way ... if > you need to send data over lossy networks > and that fits MIDI's semantics, and TCP's > head-of-line blocking latency is not acceptable, > I think RTP MIDI is the right protocol to use. Yeah, the latest value being lost is the problem, if you wanted to really solve this problem you need to make sure that value actually gets there (which you could probably do in a similar/identical way that RTP MIDI does) You're missing the big overriding point here though: RTP Midi solves this transmission problem, yes - but it solves it for _MIDI_. Using incredibly disgusting SYSEX concoctions is simply not an acceptable substitute for what many people (in this myself and Loki) use OSC for. Noone who's already gone OSC would ever actually switch back to MIDI (especially custom sysex evil that throws interoperability completely out the window). Human readability and interoperability IS often important (eg using supercollider or pd or whatever to control things). It's like pitching a modem solution to a web server problem - I'm sure its a very nice solution for modems, but noone's making a web service that speaks the Hayes command set any time soon are they? ;) Anyway, as soon as you go sysex you lose the semantics and you have the same problem anyway - retransmission is the only possible solution if you know nothing about the data (it becomes application specific). RTP MIDI may be fantastic for what it does, but it's definitely no solution for OSC things like this - there's a reason you don't see things like Supercollider, Om/Ingen, etc using MIDI for client/server comms. Anyway, this problem could easily be solved in the app if the values are echoed back (as mine are) by just resending the latest value if it didn't make it. In practise - like most people - I don't actually control realtime audio stuff over lossy networks in situations where latency matters anyway, so I havn't bothered. It would be trivial to do though. -DR- (P.S. the latency incurred by using TCP on an even remotely decent network isn't nearly as bad as people tend to assume when this comes up) ^M ^M ATH0 From forest at alittletooquiet.net Mon Jul 24 10:41:49 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Mon Jul 24 10:43:52 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153705474.9274.708.camel@c80-216-124-251.cm-upc.chello.se> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> <1153688772.32381.0.camel@localhost.localdomain> <1153705474.9274.708.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060724144149.GH4309@localdomain> > As for flexibility. If we stick to the NRPN's for a moment, we could > think of them as a huge switch-board with 127*127 destinations (msb*lsb) > each capable of holding a 14bit value. Their meaning is what we want or > need them to be. To me this seems like a flexible enough starting point. > > As for applying meaning to bit-patterns, that would depend on the > application. My own variables comes in multiples of 8 or 4 so that helps > in remembering what and where they are. I assume that RTP MIDI could be wrapped in a nice library that makes working with it a lot more pleasant? Couldn't someone implement a protocol over RTP MIDI sysex/NRPN/something that feels something like OSC at the code level? Or would that just not be very useful? -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060724/5b5d36e4/attachment-0001.bin From jayv at synth.net Mon Jul 24 10:48:12 2006 From: jayv at synth.net (Jay Vaughan) Date: Mon Jul 24 10:48:27 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <44C04885.4020801@gmail.com> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> Message-ID: >Hmm this is interesting as I have been considering doing something >similar as well. I was wondering how much of a difference having a >GUI built in a non realtime style, either in an interpreted language >or similar setup, how this might affect things for audio use. Do the engine in C. Do the GUI in C+libcairo/libcairo-svg/librsvg/libSDL. SVG is incredibly easy to use for flexible, interesting, unique GUI design and implementation. Describe the whole flow of your GUI through the SVG DOM, and away you go .. -- ; Jay Vaughan From sk at k-hornz.de Mon Jul 24 11:23:49 2006 From: sk at k-hornz.de (stefan kersten) Date: Mon Jul 24 11:25:19 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> Message-ID: <20060724152349.GG1434@localdomain> On Mon, Jul 24, 2006 at 04:48:12PM +0200, Jay Vaughan wrote: > SVG is incredibly easy to use for flexible, interesting, unique GUI > design and implementation. Describe the whole flow of your GUI > through the SVG DOM, and away you go .. could you elaborate on that? any example usage/implementation? thanks, From jayv at synth.net Mon Jul 24 11:33:41 2006 From: jayv at synth.net (Jay Vaughan) Date: Mon Jul 24 11:33:56 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724152349.GG1434@localdomain> References: <8d27a0610607200648m5ea656cfh783a46e60c0d5a1a@mail.gmail.com> <20060721070547.1e32d304.mle+la@mega-nerd.com> <9b3e2dc20607201605k580218car1e576ef423b92fe0@mail.gmail.com> <44C04885.4020801@gmail.com> <20060724152349.GG1434@localdomain> Message-ID: >could you elaborate on that? any example usage/implementation? I'm using it to build a game for the GP2X .. with an engine in C, plain ol' daemon mode, sending events to a GUI process for rendering through the SVG DOM. When I'm ready to release the package (plus source), I'll let you know .. -- ; Jay Vaughan From drobilla at connect.carleton.ca Mon Jul 24 14:11:16 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jul 24 14:11:28 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724144149.GH4309@localdomain> References: <20060722055700.6B5DE23D15B0@music.columbia.edu> <9F5A99A9-85D8-4706-92F7-D58C00466D2F@eecs.berkeley.edu> <1153643260.9274.586.camel@c80-216-124-251.cm-upc.chello.se> <1153654862.9274.630.camel@c80-216-124-251.cm-upc.chello.se> <1153688772.32381.0.camel@localhost.localdomain> <1153705474.9274.708.camel@c80-216-124-251.cm-upc.chello.se> <20060724144149.GH4309@localdomain> Message-ID: <1153764676.1076.2.camel@localhost.localdomain> On Mon, 2006-07-24 at 10:41 -0400, Forest Bond wrote: > > As for flexibility. If we stick to the NRPN's for a moment, we could > > think of them as a huge switch-board with 127*127 destinations (msb*lsb) > > each capable of holding a 14bit value. Their meaning is what we want or > > need them to be. To me this seems like a flexible enough starting point. > > > > As for applying meaning to bit-patterns, that would depend on the > > application. My own variables comes in multiples of 8 or 4 so that helps > > in remembering what and where they are. > > I assume that RTP MIDI could be wrapped in a nice library that makes working > with it a lot more pleasant? Couldn't someone implement a protocol over RTP > MIDI sysex/NRPN/something that feels something like OSC at the code level? Or > would that just not be very useful? Extending MIDI's domain past what it is currently used for is just fundamentally the Wrong Thing - the need for such a library is basically proof of that. (I'm not saying RTP MIDI is bad at all, but it's not the solution to every problem out there) -DR- From lazzaro at eecs.berkeley.edu Mon Jul 24 14:31:39 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Mon Jul 24 14:31:52 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724144356.1BDB9243CF33@music.columbia.edu> References: <20060724144356.1BDB9243CF33@music.columbia.edu> Message-ID: On Jul 24, 2006, at 7:43 AM, Carmen wrote: > >> you need to send data over lossy networks >> and that fits MIDI's semantics, and TCP's >> head-of-line blocking latency is not acceptable, > > what sort of latency is this? ~10 ms? The contract TCP makes is to deliver a stream of bytes in the order the bytes were sent. So, let's consider what happens when: [1] Packet 15 in a sequence is lost, but [2] Packets 16-20 in a sequence arrive OK. TCP can't deliver the data in packets 16-20 until it has packet 15 -- because TCP has to deliver a byte stream in the order it was sent. And so, packet 15 is at the "head of the line" blocking packets 16-20, which is why we call it "head of line blocking". Retransmitting packet 15 requires a successful round-trip (feedback from receiver to sender, and a resent packet 15 from sender to receiver), and so latency depends on the link latency and the nature of packet loss on the link. Note the latency doesn't only affect packet 15 -- packet 16-20 experience just as much latency, because they cannot be placed into the bytestream until packet 15 is placed in the bytestream. > couldn't adjusting the MTU or something else alleviate > it without having to invent "UDP + Parity Checking" ? No, see above. The problem happens because of the nature of "reliable-bytestream" TCP contract. Also, note that RTP MIDI isn't about "parity checking". It's about encoding the present state of the entire MIDI "state machine" (which Note's are down, where is each Pitch Bend, where is the sustain pedal, etc) in a journal that gets sent along with each packet. Several design tricks were used to keep the journal to a reasonable size: for example, the sender user slow feedback from the receivers to figure out what information about the MIDI state machine a receiver would need to recover from an arbitrary packet loss. This paper: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf explains the general concept of how the recovery journal works, the folks in the IETF read it and invited us to do RTP MIDI (in 2001), and then the folks in the MMA joined in the process around 2003. This paper: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/aes117.pdf was written closer to the end of the standardization process (2004, was presented at AES), although there were some changes after that to better support some of the MIDI idioms Emagic and Mackie used for Logic Control. So, for the final word on RTP MIDI implementation, see the I-Ds (soon to be RFCs) and sample code on this website: http://www.cs.berkeley.edu/~lazzaro/rtpmidi/ --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From lazzaro at eecs.berkeley.edu Mon Jul 24 16:01:14 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Mon Jul 24 16:01:24 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724144356.1BDB9243CF33@music.columbia.edu> References: <20060724144356.1BDB9243CF33@music.columbia.edu> Message-ID: <1A413CCC-38A7-4BC3-AFEF-76F0D03BFDDB@eecs.berkeley.edu> On Jul 24, 2006, at 7:43 AM, Dave Robillard wrote: > Anyway, as soon as you go sysex you lose the semantics and you have > the same > problem anyway - retransmission is the only possible solution if you > know nothing about the data (it becomes application specific). RTP MIDI has several ways to deal with this. For senders that know the semantics of what they are sending (like, say, Novation would if they were adding Wi-Fi to their keyboard line), the recovery journal syntax for SysEx lets the sender specify recovery data in a way that's suitable to the semantics, and this encoding lets a receiver figure out how to use the data to recovery. For senders that don't know the semantics of what they are sending (like a box with MIDI DIN jacks on one end and a WiFi antenna on the other), there are several options. One is to use the recovery journal encoding for SysEx that is a simple list of all commands for a type of SysEx, and rely on more frequent RTCP feedback from receiver to sender to keep the journal trimmed to a reasonable length. Alternatively, It's possible to split a MIDI cable into two RTP MIDI streams -- one TCP and one UDP -- and gate the SysEx onto the TCP stream. > (especially custom sysex evil that throws interoperability completely > out the window). Most industry folks who need to do unusual things with MIDI don't start with SysEx. They start by making analogies of what they need to do with the standard MIDI command set, and repurposing. This is partially done to make sure DAWs can edit the data, and partially done to get the efficiency of running status over the wire. SysEx is used for secondary features. You can see this design philosophy in the Logic Control specification in Appendix B of: http://manuals.info.apple.com/en/Logic7_DedicatedCntrlSurfaceInfo.pdf If I were rewriting an OSC application to use MIDI, with an eye towards good RTP MIDI loss behavior, I'd take this re-purposing approach ... it would be curious to see how Jazzmutant did it, since in their latest release of Lemur MIDI is now a full-fledged transport and not sent via OSC, if I read this web page correctly: http://www.jazzmutant.com/lemur_lastupdate.php > Human readability and interoperability IS often > important (eg using supercollider or pd or whatever to control > things). I use Structured Audio in my own work, and Eric's Scheirer's language support design for MIDI has many good aspects. See: http://www.cs.berkeley.edu/~lazzaro/sa/book/control/midi/index.html In 2006 if I were designing a replacement language, I'd do the MIDI interface language design differently, given my experience using and implementing SAOL. But I don't consider MIDI's use of SAOL as hard to program in its present state, apart from some details of extend() and turnoff for handling NoteOff release activities. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From _ at whats-your.name Mon Jul 24 16:37:27 2006 From: _ at whats-your.name (carmen) Date: Mon Jul 24 16:37:26 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1A413CCC-38A7-4BC3-AFEF-76F0D03BFDDB@eecs.berkeley.edu> References: <20060724144356.1BDB9243CF33@music.columbia.edu> <1A413CCC-38A7-4BC3-AFEF-76F0D03BFDDB@eecs.berkeley.edu> Message-ID: <20060724203727.GC11905@replic.net> On Mon Jul 24, 2006 at 01:01:14PM -0700, lazzaro wrote: > On Jul 24, 2006, at 7:43 AM, Dave Robillard wrote: > > >Anyway, as soon as you go sysex you lose the semantics and you have the same > >problem anyway - retransmission is the only possible solution if you > >know nothing about the data (it becomes application specific). > > > RTP MIDI has several ways to deal with this. what about applying the journal data to an OSC-over-UDP stream. the journal data could be encapsulated in OSC. sounds like a paper and liblo patch waiting to happen ;) From rlrevell at joe-job.com Mon Jul 24 16:38:57 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 16:39:02 2006 Subject: [linux-audio-dev] Basic MIDI question Message-ID: <1153773537.25859.114.camel@mindpipe> I've never been a MIDI expert but I'm now having to learn. I have a question about this excerpt of a MIDI file viewed with hexedit. 00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1. 00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[..^ 00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.> Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in the first line for example. I know that 0x80 is note-off, and 0x3D are note number and 0x35 the velocity of the note-off. But what the heck is the next byte, 0x31? The MIDI standard says note-off is one status byte followed by 2 data bytes! Lee From lazzaro at eecs.berkeley.edu Mon Jul 24 16:43:06 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Mon Jul 24 16:43:17 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724144356.1BDB9243CF33@music.columbia.edu> References: <20060724144356.1BDB9243CF33@music.columbia.edu> Message-ID: On Jul 24, 2006, at 7:43 AM, Forest Bond wrote: > I assume that RTP MIDI could be wrapped in a nice library that > makes working > with it a lot more pleasant? Couldn't someone implement a protocol > over RTP > MIDI sysex/NRPN/something that feels something like OSC at the code > level? Or > would that just not be very useful? My suggestion would be ... If you're creating a system where you are sending OSC and receiving OSC, just use OSC. To handle loss and reordering, use the suggestions people have made during this thread -- resilient data encoding, or application level retransmission, or engineering an essentially loss-free network, or some combination of the three. The question that brought me into the discussion originally was, if you in fact have a MIDI device, like one you bought in a store, and you want to send its data stream over a lossy network (say, Wi-Fi or the public Internet) what to do? In this case, I think having RTP MIDI built into your environment at some level makes sense. The question is, how? One way to go is to model Apple -- Tiger added networked MIDI cables to CoreMIDI, so that applications use the standard CoreMIDI API and see both direct-connect MIDI cables (via USB, Firewire, etc) and networked MIDI cables as the same thing. See: http://www.soundonsound.com/sos/jul05/articles/tiger.htm#3 for a description of how it works in OS X Tiger. For Linux, I assume this means building virtual MIDI cables into ALSA. Another option is to use a middle-ware package that has already implemented virtual MIDI cables over networks, like MIDIShare. Perhaps Dominique Fober or one of his collaborators can chime in with more details. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From letz at grame.fr Mon Jul 24 16:52:02 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_LETZ?=) Date: Mon Jul 24 16:52:04 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153773537.25859.114.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> Message-ID: <6E2B09EF-CD96-44BE-92D3-752BE44F2B9B@grame.fr> Le 24 juil. 06 ? 22:38, Lee Revell a ?crit : > I've never been a MIDI expert but I'm now having to learn. I have a > question about this excerpt of a MIDI file viewed with hexedit. > > 00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F > ".=51.:9..71..1. > 00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0 > [.. 00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK. > 6C..<&..0D.. > 00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B... > 7c..C{.p.>^ > 00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E > 11 ..:f..70..C21.> > > Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in > the first line for example. I know that 0x80 is note-off, and 0x3D > are > note number and 0x35 the velocity of the note-off. But what the > heck is > the next byte, 0x31? The MIDI standard says note-off is one status > byte > followed by 2 data bytes! > > Lee > Midi events in a Midi file are separated by time stamps see : http://www.borg.com/~jglatt/tech/midifile.htm Stephane From lars.luthman at gmail.com Mon Jul 24 16:57:15 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jul 24 16:57:25 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153773537.25859.114.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> Message-ID: <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Mon, 2006-07-24 at 16:38 -0400, Lee Revell wrote: > I've never been a MIDI expert but I'm now having to learn. I have a > question about this excerpt of a MIDI file viewed with hexedit. > > 00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1. > 00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[.. 00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C..<&..0D.. > 00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.>^ > 00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.> > > Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in > the first line for example. I know that 0x80 is note-off, and 0x3D are > note number and 0x35 the velocity of the note-off. But what the heck is > the next byte, 0x31? The MIDI standard says note-off is one status byte > followed by 2 data bytes! That's the standard for MIDI that is sent realtime over a wire. When it is stored in a file you also need some sort of timestamp for each event. The extra byte is the number of clock ticks to wait before you play the event (since the last event). -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060724/bdd21ec3/attachment.bin From lazzaro at eecs.berkeley.edu Mon Jul 24 16:59:14 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Mon Jul 24 16:59:54 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724203901.45C0D244A191@music.columbia.edu> References: <20060724203901.45C0D244A191@music.columbia.edu> Message-ID: <432336F4-1315-4C77-B7B7-5D0A736C95FE@eecs.berkeley.edu> On Jul 24, 2006, at 1:39 PM, linux-audio-dev- request@music.columbia.edu wrote: > what about applying the journal data to an OSC-over-UDP stream. the > journal data could be encapsulated in OSC. sounds like a paper and > liblo patch waiting to happen ;) Personally, my suggestion is that the community starts by defining OSC profiles for specific classes of gestural input and synthesis methods that are widely used in the community. These profiles should standardize syntax and semantics. If you are working on a music project that is doing something that fits a profile, use the profile. Otherwise, do as you do today. If OSC goes down this route, one can imagine developing a recovery-journal system with recovery semantics for all the standard profiles. Part of developing a new OSC profile would be defining the recovery journal for the profile. The least of the benefits of a design like this would be network resiliency. The big win is by defining OSC profiles with semantics, it starts to make sense to create a hardware or software synth that "understands OSC profile X" out of the box, in the same way a synth understands MIDI. And you can also create mass-market controller hardware that "puts out OSC data using profile X". And so, you can connect the two boxes up and get plug and play -- just like MIDI. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From rlrevell at joe-job.com Mon Jul 24 17:09:02 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 17:08:34 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <1153775343.25859.125.camel@mindpipe> On Mon, 2006-07-24 at 22:57 +0200, Lars Luthman wrote: > On Mon, 2006-07-24 at 16:38 -0400, Lee Revell wrote: > > I've never been a MIDI expert but I'm now having to learn. I have a > > question about this excerpt of a MIDI file viewed with hexedit. > > > > 00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1. > > 00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[.. > 00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C..<&..0D.. > > 00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.>^ > > 00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.> > > > > Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in > > the first line for example. I know that 0x80 is note-off, and 0x3D are > > note number and 0x35 the velocity of the note-off. But what the heck is > > the next byte, 0x31? The MIDI standard says note-off is one status byte > > followed by 2 data bytes! > > That's the standard for MIDI that is sent realtime over a wire. When it > is stored in a file you also need some sort of timestamp for each event. > The extra byte is the number of clock ticks to wait before you play the > event (since the last event). > OK. I was confused because I also see these timestamps when snooping the MIDI output stream inside the kernel's MPU401 driver. I guess I assumed that aplaymidi would deliver the events with correct timing, rather than passing the timestamps through. I guess if I played back the same MIDI file with a full featured sequencer, I would only see the actual MIDI events in the driver? Also, why doesn't every event have a timestamp? For example "81 0C 90 30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in one "tick"? Lee From pedro.lopez.cabanillas at gmail.com Mon Jul 24 17:11:52 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Mon Jul 24 17:12:11 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060724203901.5DBCD244A194@music.columbia.edu> References: <20060724203901.5DBCD244A194@music.columbia.edu> Message-ID: <200607242311.53011.pedro.lopez.cabanillas@gmail.com> On Monday, 24 July 2006 16:38, Lee Revell wrote: > Take the sequence "80 3D 35 ?31 80 3A 39 ?0E 80 37 31 ?03 80 31 1F" in > the first line for example. ?I know that 0x80 is note-off, and 0x3D are > note number and 0x35 the velocity of the note-off. ?But what the heck is > the next byte, 0x31? ? Delta time of the next event, in variable length representation. > The MIDI standard says note-off is one status byte > followed by 2 data bytes! SMF (Standard MIDI File) format must store timestamped events, which the MIDI protocol (over the wire) doesn't care. There is a good reference of SMF format here: http://borg.com/~jglatt/tech/midifile.htm You may want to try some SMF-to-text conversion utility: http://alsa.opensrc.org/MidiComp Regards, Pedro From nipo at ssji.net Mon Jul 24 19:43:57 2006 From: nipo at ssji.net (Nicolas Pouillon) Date: Mon Jul 24 17:44:07 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153775343.25859.125.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> Message-ID: <20060725014357.36fd468d.nipo@ssji.net> [Mon, 24 Jul 2006 17:09:02 -0400] Lee Revell eut le bonheur d'_crire: > Also, why doesn't every event have a timestamp? For example "81 0C 90 > 30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in > one "tick"? Actually delta times between events are encoded with a variable length value. As long as bit 7 is 1, you must drop this very bit and add next byte in the value decoding. Here; 81 0c is a variable length value: delta 81 0c which is ((0x7f & 0x81) << 7) | 0x0c = 0x8c event 90 30 5b delta 00 event 90 3c 78 delta 81 70 which is 0xf0 hth -- Nipo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060725/a1b9625c/attachment.bin From rlrevell at joe-job.com Mon Jul 24 17:55:17 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 17:54:44 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060725014357.36fd468d.nipo@ssji.net> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> Message-ID: <1153778118.25859.136.camel@mindpipe> On Tue, 2006-07-25 at 01:43 +0200, Nicolas Pouillon wrote: > [Mon, 24 Jul 2006 17:09:02 -0400] > Lee Revell eut le bonheur d'_crire: > > > Also, why doesn't every event have a timestamp? For example "81 0C 90 > > 30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in > > one "tick"? > > Actually delta times between events are encoded with a variable length > value. As long as bit 7 is 1, you must drop this very bit and add next > byte in the value decoding. Here; 81 0c is a variable length value: > > delta 81 0c which is ((0x7f & 0x81) << 7) | 0x0c = 0x8c > event 90 30 5b > delta 00 > event 90 3c 78 > delta 81 70 which is 0xf0 > > hth > Ugh. All I need to do is snoop note on, note off, and the note number. But you're saying that 0x81 is sometimes part of a timestamp, and other times it means note off on channel 1? So you are saying my driver needs to have full knowledge of the MIDI state machine in order to snoop note on and note off? Lee From nipo at ssji.net Mon Jul 24 20:23:39 2006 From: nipo at ssji.net (Nicolas Pouillon) Date: Mon Jul 24 18:23:33 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153778118.25859.136.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> Message-ID: <20060725022339.f71a62bb.nipo@ssji.net> [Mon, 24 Jul 2006 17:55:17 -0400] Lee Revell eut le bonheur d'_crire: > Ugh. All I need to do is snoop note on, note off, and the note number. > But you're saying that 0x81 is sometimes part of a timestamp, and other > times it means note off on channel 1? Bytes you read, when decoding smf-like stream (which is to say with delta times in between) must be decoded differently whether you are reading an event or a delta time, yes > So you are saying my driver needs to have full knowledge of the MIDI > state machine in order to snoop note on and note off? I believe so. You also may have to care about other midi specific things to parse like -Running command: Command byte (the one with 1 on bit 7) may be ommited if it is the same as last one -"Note on" with velocity 0 is considered as "note off" (most of the time) 91 42 7f 81 30 91 41 3e 88 37 81 42 00 30 81 41 00 may be optimized as (-- is an ommited repeated "running" command byte) 91 42 7f 81 30 -- 41 3e 88 37 81 42 00 30 -- 41 00 or even 91 42 7f 81 30 -- 41 3e 88 37 -- 42 00 30 -- 41 00 -- Nipo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060725/92875f13/attachment.bin From renich at woralelandia.com Mon Jul 24 19:04:46 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Mon Jul 24 19:04:19 2006 Subject: [linux-audio-dev] Akai's MPC4000 Sampler/Workstation Open Source Project Message-ID: <44C5520E.1040601@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060724/194dbc44/renich.vcf From jens.andreasen at chello.se Mon Jul 24 19:19:05 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Jul 24 19:19:27 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153778118.25859.136.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> Message-ID: <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: > Ugh. All I need to do is snoop note on, note off, and the note number. > But you're saying that 0x81 is sometimes part of a timestamp, and other > times it means note off on channel 1? > > So you are saying my driver needs to have full knowledge of the MIDI > state machine in order to snoop note on and note off? > Driver? This is a driver for a midi-port on a sound-card or a some kind of midi-file player? /jens > Lee > -- From rlrevell at joe-job.com Mon Jul 24 19:28:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 19:28:10 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153783721.25859.154.camel@mindpipe> On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote: > On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: > > > Ugh. All I need to do is snoop note on, note off, and the note number. > > But you're saying that 0x81 is sometimes part of a timestamp, and other > > times it means note off on channel 1? > > > > So you are saying my driver needs to have full knowledge of the MIDI > > state machine in order to snoop note on and note off? > > > Driver? This is a driver for a midi-port on a sound-card or a some kind > of midi-file player? It's similar to a driver for a MIDI port on a sound card, except the driver additionally has to respond to note on and note off by twiddling some other bits in the hardware. It's equivalent to having to flash an LED for note on and another for note off. I wrote the driver as an ALSA rawmidi device, which was probably not the best idea - I did not realize at the time that I would have to interpret the MIDI stream. An ALSA kernel sequencer client would have been more appropriate. I think I can get away with always treating 0x90 as note on and 0x80 as note off regardless of the context. (I can't release source or give the hardware details now, as the hardware is still being developed) Lee From jens.andreasen at chello.se Mon Jul 24 19:33:11 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Jul 24 19:33:20 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153783721.25859.154.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> <1153783721.25859.154.camel@mindpipe> Message-ID: <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-07-24 at 19:28 -0400, Lee Revell wrote: > On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote: > > On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: > > > > > Ugh. All I need to do is snoop note on, note off, and the note number. > > > But you're saying that 0x81 is sometimes part of a timestamp, and other > > > times it means note off on channel 1? > > > > > > So you are saying my driver needs to have full knowledge of the MIDI > > > state machine in order to snoop note on and note off? > > > > > Driver? This is a driver for a midi-port on a sound-card or a some kind > > of midi-file player? > > It's similar to a driver for a MIDI port on a sound card, except the > driver additionally has to respond to note on and note off by twiddling > some other bits in the hardware. It's equivalent to having to flash an > LED for note on and another for note off. > > I wrote the driver as an ALSA rawmidi device, which was probably not the > best idea - I did not realize at the time that I would have to interpret > the MIDI stream. An ALSA kernel sequencer client would have been more > appropriate. Confused again here. There are no delta-times in the midi-stream. You mean: " ... have to interpret the midi *file*" > > I think I can get away with always treating 0x90 as note on and 0x80 as > note off regardless of the context. > > (I can't release source or give the hardware details now, as the > hardware is still being developed) > > Lee > -- From rlrevell at joe-job.com Mon Jul 24 19:38:47 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 19:38:15 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> <1153783721.25859.154.camel@mindpipe> <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153784328.25859.160.camel@mindpipe> On Tue, 2006-07-25 at 01:33 +0200, Jens M Andreasen wrote: > On Mon, 2006-07-24 at 19:28 -0400, Lee Revell wrote: > > On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote: > > > On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote: > > > > > > > Ugh. All I need to do is snoop note on, note off, and the note number. > > > > But you're saying that 0x81 is sometimes part of a timestamp, and other > > > > times it means note off on channel 1? > > > > > > > > So you are saying my driver needs to have full knowledge of the MIDI > > > > state machine in order to snoop note on and note off? > > > > > > > Driver? This is a driver for a midi-port on a sound-card or a some kind > > > of midi-file player? > > > > It's similar to a driver for a MIDI port on a sound card, except the > > driver additionally has to respond to note on and note off by twiddling > > some other bits in the hardware. It's equivalent to having to flash an > > LED for note on and another for note off. > > > > I wrote the driver as an ALSA rawmidi device, which was probably not the > > best idea - I did not realize at the time that I would have to interpret > > the MIDI stream. An ALSA kernel sequencer client would have been more > > appropriate. > > Confused again here. There are no delta-times in the midi-stream. You > mean: " ... have to interpret the midi *file*" > I think it's me that's confused - as you can see I'm certainly not a MIDI expert. When playing a MIDI file to a rawmidi port with aplaymidi, it was not clear to me that it just passes the file through - I was under the impression that the driver would only see the actual events, not the timestamps and other metadata. Lee From jens.andreasen at chello.se Mon Jul 24 19:47:04 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Jul 24 19:47:17 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153784328.25859.160.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> <1153783721.25859.154.camel@mindpipe> <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> <1153784328.25859.160.camel@mindpipe> Message-ID: <1153784824.9274.826.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-07-24 at 19:38 -0400, Lee Revell wrote: > I think it's me that's confused - as you can see I'm certainly not a > MIDI expert. > > When playing a MIDI file to a rawmidi port ... $man aplaymidi -p, --port=client:port,... Sets the sequencer port(s) to which the events in the MIDI file(s) are sent. ------------------------------------------------- I think it is unpossible to make it use rawmidi. Says sequencer (which will do the timing.) Can you jack in after the sequencer has performed its magic, and you have the actual midi-stream? > with aplaymidi, it was not > clear to me that it just passes the file through - I was under the > impression that the driver would only see the actual events, not the > timestamps and other metadata. > > Lee > -- From rlrevell at joe-job.com Mon Jul 24 19:53:02 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jul 24 19:52:45 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153784824.9274.826.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> <1153783721.25859.154.camel@mindpipe> <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> <1153784328.25859.160.camel@mindpipe> <1153784824.9274.826.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153785182.25859.168.camel@mindpipe> On Tue, 2006-07-25 at 01:47 +0200, Jens M Andreasen wrote: > On Mon, 2006-07-24 at 19:38 -0400, Lee Revell wrote: > > > I think it's me that's confused - as you can see I'm certainly not a > > MIDI expert. > > > > When playing a MIDI file to a rawmidi port ... > > $man aplaymidi > > -p, --port=client:port,... > > Sets the sequencer port(s) to which the events > in the MIDI file(s) are sent. > ------------------------------------------------- > > I think it is unpossible to make it use rawmidi. ALSA takes care of the sequencer port<->rawmidi device translation. > Says sequencer (which > will do the timing.) Can you jack in after the sequencer has performed > its magic, and you have the actual midi-stream? > I thought I was doing exactly what you suggect, by looking at the data in the driver right before it goes to the hardware. I'll just use a real sequencer for testing rather than aplaymidi. Lee From drobilla at connect.carleton.ca Mon Jul 24 20:18:59 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jul 24 20:19:09 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <432336F4-1315-4C77-B7B7-5D0A736C95FE@eecs.berkeley.edu> References: <20060724203901.45C0D244A191@music.columbia.edu> <432336F4-1315-4C77-B7B7-5D0A736C95FE@eecs.berkeley.edu> Message-ID: <1153786739.1371.3.camel@localhost.localdomain> On Mon, 2006-07-24 at 13:59 -0700, lazzaro wrote: > On Jul 24, 2006, at 1:39 PM, linux-audio-dev- > request@music.columbia.edu wrote: > > > what about applying the journal data to an OSC-over-UDP stream. the > > journal data could be encapsulated in OSC. sounds like a paper and > > liblo patch waiting to happen ;) > > > Personally, my suggestion is that the community starts by > defining OSC profiles for specific classes of gestural input > and synthesis methods that are widely used in the community. > These profiles should standardize syntax and semantics. If > you are working on a music project that is doing something > that fits a profile, use the profile. Otherwise, do as you do today. > > If OSC goes down this route, one can imagine developing a > recovery-journal system with recovery semantics for all the > standard profiles. Part of developing a new OSC profile would > be defining the recovery journal for the profile. > > The least of the benefits of a design like this would be > network resiliency. The big win is by defining OSC profiles > with semantics, it starts to make sense to create a hardware > or software synth that "understands OSC profile X" out of > the box, in the same way a synth understands MIDI. And > you can also create mass-market controller hardware that > "puts out OSC data using profile X". And so, you can > connect the two boxes up and get plug and play -- just > like MIDI. But you don't "just get plug and play" with MIDI. It's all about learning with MIDI. At the very least with OSC you need to have a (dynamically changeable) path prefix for everything (eg such a defined "profile" would definitely have to allow for an undefined prefix portion), so no matter how you slice it you end up needing some sort of "learn"-ish system anyway. So even with such profiles the real problem to be solved is still service discovery and namespace enumeration (eg back to square one). -DR- From loki.davison at gmail.com Mon Jul 24 20:27:34 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Jul 24 20:27:41 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <1153786739.1371.3.camel@localhost.localdomain> References: <20060724203901.45C0D244A191@music.columbia.edu> <432336F4-1315-4C77-B7B7-5D0A736C95FE@eecs.berkeley.edu> <1153786739.1371.3.camel@localhost.localdomain> Message-ID: On 7/25/06, Dave Robillard wrote: > On Mon, 2006-07-24 at 13:59 -0700, lazzaro wrote: > > On Jul 24, 2006, at 1:39 PM, linux-audio-dev- > > request@music.columbia.edu wrote: > > > > > what about applying the journal data to an OSC-over-UDP stream. the > > > journal data could be encapsulated in OSC. sounds like a paper and > > > liblo patch waiting to happen ;) > > > > > > Personally, my suggestion is that the community starts by > > defining OSC profiles for specific classes of gestural input > > and synthesis methods that are widely used in the community. > > These profiles should standardize syntax and semantics. If > > you are working on a music project that is doing something > > that fits a profile, use the profile. Otherwise, do as you do today. > > > > If OSC goes down this route, one can imagine developing a > > recovery-journal system with recovery semantics for all the > > standard profiles. Part of developing a new OSC profile would > > be defining the recovery journal for the profile. > > > > The least of the benefits of a design like this would be > > network resiliency. The big win is by defining OSC profiles > > with semantics, it starts to make sense to create a hardware > > or software synth that "understands OSC profile X" out of > > the box, in the same way a synth understands MIDI. And > > you can also create mass-market controller hardware that > > "puts out OSC data using profile X". And so, you can > > connect the two boxes up and get plug and play -- just > > like MIDI. > > But you don't "just get plug and play" with MIDI. It's all about > learning with MIDI. > > At the very least with OSC you need to have a (dynamically changeable) > path prefix for everything (eg such a defined "profile" would definitely > have to allow for an undefined prefix portion), so no matter how you > slice it you end up needing some sort of "learn"-ish system anyway. So > even with such profiles the real problem to be solved is still service > discovery and namespace enumeration (eg back to square one). > > -DR- speaking of which, liboscqs anyone? I'm doing bugger all coding lad stuff at the moment as I code at work, and play my lovely new semi hollow guitar at home, but a bit of momentum in all the OSC using things with liboscqs would be very nice. If there is one fully working example of actual use in an app it would be easy to then port it to others apps. It looks really handy. Loki From jens.andreasen at chello.se Mon Jul 24 20:29:05 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Jul 24 20:29:15 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153785182.25859.168.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725014357.36fd468d.nipo@ssji.net> <1153778118.25859.136.camel@mindpipe> <1153783145.9274.815.camel@c80-216-124-251.cm-upc.chello.se> <1153783721.25859.154.camel@mindpipe> <1153783991.9274.819.camel@c80-216-124-251.cm-upc.chello.se> <1153784328.25859.160.camel@mindpipe> <1153784824.9274.826.camel@c80-216-124-251.cm-upc.chello.se> <1153785182.25859.168.camel@mindpipe> Message-ID: <1153787345.9274.835.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2006-07-24 at 19:53 -0400, Lee Revell wrote: > > will do the timing.) Can you jack in after the sequencer has performed > > its magic, and you have the actual midi-stream? > > > > I thought I was doing exactly what you suggect, by looking at the data > in the driver right before it goes to the hardware. > > I'll just use a real sequencer for testing rather than aplaymidi. > Virtual Midi perhaps? a virtual midi device that shows up in both ALSA and OSS. Route aplaymidi to the first virtual port and read the raw stream from the new port called /dev/midi? (one number higher than the highest number you had before) # insmod snd_virmidi > Lee > -- From clemens at ladisch.de Tue Jul 25 05:03:56 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue Jul 25 05:04:25 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153775343.25859.125.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> Message-ID: <20060725090356.GC23978@turing.informatik.uni-halle.de> Lee Revell wrote: > I was confused because I also see these timestamps when snooping > the MIDI output stream inside the kernel's MPU401 driver. I guess I > assumed that aplaymidi would deliver the events with correct timing, > rather than passing the timestamps through. The MIDI data at a raw MIDI port never has timestamps. What you see are the data bytes of the next MIDI command where the command byte itself has been omitted because it would be identical to the last one. (ALSA's sequencer event -> rawmidi converter uses running status by default.) The running status and the zero note-on velocity (see Nicolas' mail) are the only special cases your parser has to look out for. HTH Clemens From rlrevell at joe-job.com Tue Jul 25 10:26:33 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jul 25 10:26:08 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060725090356.GC23978@turing.informatik.uni-halle.de> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> Message-ID: <1153837594.25859.191.camel@mindpipe> On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > (ALSA's > sequencer event -> rawmidi converter uses running status by default.) "By default" - so it can it be disabled? How? Lee From clemens at ladisch.de Tue Jul 25 12:11:39 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue Jul 25 12:11:57 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153837594.25859.191.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> Message-ID: <20060725161139.GD27837@turing.informatik.uni-halle.de> Lee Revell wrote: > On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > > (ALSA's > > sequencer event -> rawmidi converter uses running status by default.) > > "By default" - so it can it be disabled? How? snd_midi_event_no_status(), but this cannot be changed by a driver. This setting wouldn't apply to data written directly to the rawmidi port anyway. Regards, Clemens From rlrevell at joe-job.com Tue Jul 25 12:32:13 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jul 25 12:31:38 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060725161139.GD27837@turing.informatik.uni-halle.de> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <20060725161139.GD27837@turing.informatik.uni-halle.de> Message-ID: <1153845134.25859.204.camel@mindpipe> On Tue, 2006-07-25 at 18:11 +0200, Clemens Ladisch wrote: > Lee Revell wrote: > > On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > > > (ALSA's > > > sequencer event -> rawmidi converter uses running status by default.) > > > > "By default" - so it can it be disabled? How? > > snd_midi_event_no_status(), but this cannot be changed by a driver. > This setting wouldn't apply to data written directly to the rawmidi port > anyway. It would in fact be useful for my testing to add a command line option to aplaymidi to have it not use running status. But, I see that aplaymidi rolls its own events rather than using snd_midi_event_t, so it's not at all clear how to do it. Lee From drobilla at connect.carleton.ca Tue Jul 25 12:32:38 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 25 12:33:47 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060724203727.GC11905@replic.net> References: <20060724144356.1BDB9243CF33@music.columbia.edu> <1A413CCC-38A7-4BC3-AFEF-76F0D03BFDDB@eecs.berkeley.edu> <20060724203727.GC11905@replic.net> Message-ID: <1153845158.1925.2.camel@localhost.localdomain> On Mon, 2006-07-24 at 20:37 +0000, carmen wrote: > On Mon Jul 24, 2006 at 01:01:14PM -0700, lazzaro wrote: > > On Jul 24, 2006, at 7:43 AM, Dave Robillard wrote: > > > > >Anyway, as soon as you go sysex you lose the semantics and you have the same > > >problem anyway - retransmission is the only possible solution if you > > >know nothing about the data (it becomes application specific). > > > > > > RTP MIDI has several ways to deal with this. > > what about applying the journal data to an OSC-over-UDP stream. the journal data could be encapsulated in OSC. sounds like a paper and liblo patch waiting to happen ;) Can't, there's no semantics to work with (and so no state machine, which the entire thing is based on). Something similar /could/ be done, but a whole lot of difficult stuff needs to be done first (the "OSC semantic templates" lazzaro mentioned, service discovery, etc, etc). Personally I want the stuff that would need to be done first directly more than this RTP thing :) Maybe one day.. -DR- From drobilla at connect.carleton.ca Tue Jul 25 12:36:58 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 25 12:37:06 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: References: <20060724203901.45C0D244A191@music.columbia.edu> <432336F4-1315-4C77-B7B7-5D0A736C95FE@eecs.berkeley.edu> <1153786739.1371.3.camel@localhost.localdomain> Message-ID: <1153845418.1925.6.camel@localhost.localdomain> On Tue, 2006-07-25 at 10:27 +1000, Loki Davison wrote: > On 7/25/06, Dave Robillard wrote: > > On Mon, 2006-07-24 at 13:59 -0700, lazzaro wrote: > > > On Jul 24, 2006, at 1:39 PM, linux-audio-dev- > > > request@music.columbia.edu wrote: > > > > > > > what about applying the journal data to an OSC-over-UDP stream. the > > > > journal data could be encapsulated in OSC. sounds like a paper and > > > > liblo patch waiting to happen ;) > > > > > > > > > Personally, my suggestion is that the community starts by > > > defining OSC profiles for specific classes of gestural input > > > and synthesis methods that are widely used in the community. > > > These profiles should standardize syntax and semantics. If > > > you are working on a music project that is doing something > > > that fits a profile, use the profile. Otherwise, do as you do today. > > > > > > If OSC goes down this route, one can imagine developing a > > > recovery-journal system with recovery semantics for all the > > > standard profiles. Part of developing a new OSC profile would > > > be defining the recovery journal for the profile. > > > > > > The least of the benefits of a design like this would be > > > network resiliency. The big win is by defining OSC profiles > > > with semantics, it starts to make sense to create a hardware > > > or software synth that "understands OSC profile X" out of > > > the box, in the same way a synth understands MIDI. And > > > you can also create mass-market controller hardware that > > > "puts out OSC data using profile X". And so, you can > > > connect the two boxes up and get plug and play -- just > > > like MIDI. > > > > But you don't "just get plug and play" with MIDI. It's all about > > learning with MIDI. > > > > At the very least with OSC you need to have a (dynamically changeable) > > path prefix for everything (eg such a defined "profile" would definitely > > have to allow for an undefined prefix portion), so no matter how you > > slice it you end up needing some sort of "learn"-ish system anyway. So > > even with such profiles the real problem to be solved is still service > > discovery and namespace enumeration (eg back to square one). > > > > -DR- > > speaking of which, liboscqs anyone? I'm doing bugger all coding lad > stuff at the moment as I code at work, and play my lovely new semi > hollow guitar at home, but a bit of momentum in all the OSC using > things with liboscqs would be very nice. If there is one fully working > example of actual use in an app it would be easy to then port it to > others apps. It looks really handy. It's on my TODO list. ... It's a big list. :) -DR- From drobilla at connect.carleton.ca Tue Jul 25 12:38:50 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 25 12:38:57 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060725090356.GC23978@turing.informatik.uni-halle.de> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> Message-ID: <1153845530.1925.9.camel@localhost.localdomain> On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > Lee Revell wrote: > > I was confused because I also see these timestamps when snooping > > the MIDI output stream inside the kernel's MPU401 driver. I guess I > > assumed that aplaymidi would deliver the events with correct timing, > > rather than passing the timestamps through. > > The MIDI data at a raw MIDI port never has timestamps. What you see are > the data bytes of the next MIDI command where the command byte itself > has been omitted because it would be identical to the last one. (ALSA's > sequencer event -> rawmidi converter uses running status by default.) > > The running status and the zero note-on velocity (see Nicolas' mail) are > the only special cases your parser has to look out for. What about the 1-byte "realtime" events? (un-normalized MIDI reeally sucks...) -DR- From jens.andreasen at chello.se Tue Jul 25 12:53:17 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Jul 25 12:54:06 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153837594.25859.191.camel@mindpipe> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> Message-ID: <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> On Tue, 2006-07-25 at 10:26 -0400, Lee Revell wrote: > On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > > (ALSA's > > sequencer event -> rawmidi converter uses running status by default.) > > "By default" - so it can it be disabled? How? > Are you sure you would want to do that? Because running status by itself would be just: for(;;) { thisByte = nextByte(); if(thisByte & 0x80) runningStatus = thisByte; //... after which we get that: if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) { thisByte = nextByte(); thisByte = nextByte(); // note_on with zero velocity is note_off if(thisByte == 0 || runningStatus == NOTE_OFF) setLed(NOTE_OFF); else setLed(NOTE_ON); } } > Lee > -- From jens.andreasen at chello.se Tue Jul 25 13:00:54 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Jul 25 13:01:02 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> Bzzzt ... My wrong! thisByte = nextByte(); for(;;) { if(thisByte & 0x80) runningStatus = thisByte; //... after which we get that: if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) { thisByte = nextByte(); thisByte = nextByte(); // note_on with zero velocity is note_off if(thisByte == 0 || runningStatus == NOTE_OFF) setLed(NOTE_OFF); else setLed(NOTE_ON); } else thisByte = nextByte(); } > > Lee > > -- From lazzaro at eecs.berkeley.edu Tue Jul 25 14:38:00 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Tue Jul 25 14:38:14 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <20060725163346.CC7222475331@music.columbia.edu> References: <20060725163346.CC7222475331@music.columbia.edu> Message-ID: <88ECD380-9EEC-461A-AED4-0B8A5F1C2894@eecs.berkeley.edu> On Jul 25, 2006, at 9:33 AM, Dave Robillard wrote: > But you don't "just get plug and play" with MIDI. It's all about > learning with MIDI. "Common things should be easy, and unusual things should be possible". The common things in MIDI are plug-and-play. Only the "unusual things" are "all about learning". NoteOn and NoteOff, sustain pedal, volume control, stereo pan, pitch-bend, mod-wheel ... these are all plug-and-play, and have been since the earliest days of MIDI. Manufacturers who make controllers know to send out these commands in a stylized way, and sound designers who write patches for synths (soft and hard) know to make their synths respond in an appropriate way to these controllers. And for a lot musicians, this is enough for them to do what they want to do. This is the MIDI world Garageband lives in, for example, and the biggest problem Apple has with Garageband is that it is an entry-level program that makes most of its users so happy that they aren't interested in upgrading to semi-pro software. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From renich at woralelandia.com Tue Jul 25 15:18:54 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Tue Jul 25 15:18:23 2006 Subject: [linux-audio-dev] Open MPC OS Initiative Message-ID: <44C66E9E.9040806@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060725/a471aed7/renich.vcf From rlrevell at joe-job.com Tue Jul 25 15:25:47 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jul 25 15:25:24 2006 Subject: [linux-audio-dev] Open MPC OS Initiative In-Reply-To: <44C66E9E.9040806@woralelandia.com> References: <44C66E9E.9040806@woralelandia.com> Message-ID: <1153855549.25859.217.camel@mindpipe> Plain text mail is preferred over HTML on this list. On Tue, 2006-07-25 at 14:18 -0500, Renich Bon ?iri? wrote: > If anyone would like to join the OpenMPC OS dev team, welcome. > > http://www.woralelandia.com/openmpc/blog/ Are you attempting to port Linux to it, or develop a new OS from the ground up? Lee From jacob01 at gmx.net Tue Jul 25 15:33:29 2006 From: jacob01 at gmx.net (Jacob) Date: Tue Jul 25 15:34:19 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153845530.1925.9.camel@localhost.localdomain> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153845530.1925.9.camel@localhost.localdomain> Message-ID: <20060725193328.GD14390@localhost> On Tue, Jul 25, 2006 at 12:38:50PM -0400, Dave Robillard wrote: > On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote: > > Lee Revell wrote: > > The running status and the zero note-on velocity (see Nicolas' mail) are > > the only special cases your parser has to look out for. > > What about the 1-byte "realtime" events? IIRC, real-time events (1 byte, status byte 0xf8 - 0xff) may happen at _any time_ (even between 2 data bytes) without affecting the current message. That includes that it must not be remembered as last status byte (real-time messages don't have data bytes). Another issue are system common messages (0xf0 - 0xf7). These status codes must not be stored as running status either, so there must be a status byte after each system common message. But this is not an issue here I think, I just added it for completeness. Jacob > > (un-normalized MIDI reeally sucks...) > > -DR- > > From drobilla at connect.carleton.ca Tue Jul 25 15:54:10 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jul 25 15:54:22 2006 Subject: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV] In-Reply-To: <88ECD380-9EEC-461A-AED4-0B8A5F1C2894@eecs.berkeley.edu> References: <20060725163346.CC7222475331@music.columbia.edu> <88ECD380-9EEC-461A-AED4-0B8A5F1C2894@eecs.berkeley.edu> Message-ID: <1153857250.2119.5.camel@localhost.localdomain> On Tue, 2006-07-25 at 11:38 -0700, lazzaro wrote: > On Jul 25, 2006, at 9:33 AM, Dave Robillard > wrote: > > > But you don't "just get plug and play" with MIDI. It's all about > > learning with MIDI. > > > "Common things should be easy, and unusual things > should be possible". The common things in MIDI are > plug-and-play. Only the "unusual things" are "all about > learning". > > NoteOn and NoteOff, sustain pedal, volume control, > stereo pan, pitch-bend, mod-wheel ... these are all > plug-and-play, and have been since the earliest days of MIDI. > > Manufacturers who make controllers know to send out these > commands in a stylized way, and sound designers who write > patches for synths (soft and hard) know to make their synths > respond in an appropriate way to these controllers. And for > a lot musicians, this is enough for them to do what they want > to do. This is the MIDI world Garageband lives in, for example, > and the biggest problem Apple has with Garageband is that > it is an entry-level program that makes most of its users so happy > that they aren't interested in upgrading to semi-pro software. True. I'm sure we'll have a note standard for OSC as soon as there's a need for one, but (unfortunately) right now there isn't. There aren't really any devices/apps to send those notes anyway (though a few things I'm working on ATM will likely require one). You still need the service discovery etc. to get that prefix path though (which is basically the vastly superior OSC equivalent to MIDI's channels) - it's a bit more complicated than MIDI by nature, but not terribly so. -DR- From jacob01 at gmx.net Tue Jul 25 15:55:32 2006 From: jacob01 at gmx.net (Jacob) Date: Tue Jul 25 15:56:05 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060725195532.GE14390@localhost> Hmmm, does this really work? I don't think so. Example: 1. status: note on (-> thisByte -> runningStatus) 2. data: key (-> thisByte, ignored) 3. data: vel (-> thisByte, checked against 0, checked againt 0x80) 4. status: note off (read as key !!!) 5. data: key (read as vel, checked against 0x80 !!!) 6. data: vel (read as key !!!) 7. status: note on (read as vel, checked against 0x80 !!!) The Problem is, that the second data byte is used for the running status byte test. Yours, Jacob On Tue, Jul 25, 2006 at 07:00:54PM +0200, Jens M Andreasen wrote: > Bzzzt ... My wrong! > > > thisByte = nextByte(); > > for(;;) > { > > if(thisByte & 0x80) > runningStatus = thisByte; > > //... after which we get that: > > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) > { > thisByte = nextByte(); > thisByte = nextByte(); > > // note_on with zero velocity is note_off > if(thisByte == 0 || runningStatus == NOTE_OFF) > setLed(NOTE_OFF); > else > setLed(NOTE_ON); > } > else > thisByte = nextByte(); > } > > > Lee > > > > -- > From renich at woralelandia.com Tue Jul 25 16:30:13 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Tue Jul 25 16:29:44 2006 Subject: [linux-audio-dev] Open MPC OS Initiative In-Reply-To: <1153855549.25859.217.camel@mindpipe> References: <44C66E9E.9040806@woralelandia.com> <1153855549.25859.217.camel@mindpipe> Message-ID: <44C67F55.8030507@woralelandia.com> I am not sure. I really am not. I am no programmer. I am just organizing things. Porting linux would be super cool! We have some other kernel source around. I am gonna end up posting everything at the blog. Im on it. Lee Revell wrote: > Plain text mail is preferred over HTML on this list. > > On Tue, 2006-07-25 at 14:18 -0500, Renich Bon ?iri? wrote: > >> If anyone would like to join the OpenMPC OS dev team, welcome. >> >> http://www.woralelandia.com/openmpc/blog/ >> > > Are you attempting to port Linux to it, or develop a new OS from the > ground up? > > Lee > > -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060725/5c861c19/renich.vcf From jens.andreasen at chello.se Tue Jul 25 19:55:33 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Jul 25 19:55:42 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060725195532.GE14390@localhost> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> Message-ID: <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> On Tue, 2006-07-25 at 21:55 +0200, Jacob wrote: > Hmmm, does this really work? I don't think so. > > Example: > > 1. status: note on (-> thisByte -> runningStatus) > 2. data: key (-> thisByte, ignored) > 3. data: vel (-> thisByte, checked against 0, checked againt 0x80) > 4. status: note off (read as key !!!) > 5. data: key (read as vel, checked against 0x80 !!!) > 6. data: vel (read as key !!!) > 7. status: note on (read as vel, checked against 0x80 !!!) > > The Problem is, that the second data byte is used for the running status > byte test. > > Yours, > > Jacob Ehmm ... Right! Just checking if you were awake :-D Furthermore, it did not do the single byte SysRt either. But there ought to be a small, reasonable solution out there somewhere ... Giving it one more try: for(;;) { thisByte = nextByte(); if(thisByte & 0x80) // got new status runningStatus = thisByte, count = 0; if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) { while(count < 2) // we need data1 and data2 { thisByte = nextByte(); // filter out single byte SysRt count += !(thisByte & 0x80); } if(thisByte == 0 || runningStatus == NOTE_OFF) setLed(NOTE_OFF); else setLed(NOTE_ON); // assume we will keep runningStatus count = 1; } } > On Tue, Jul 25, 2006 at 07:00:54PM +0200, Jens M Andreasen wrote: > > Bzzzt ... My wrong! > > > > > > thisByte = nextByte(); > > > > for(;;) > > { > > > > if(thisByte & 0x80) > > runningStatus = thisByte; > > > > //... after which we get that: > > > > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) > > { > > thisByte = nextByte(); > > thisByte = nextByte(); > > > > // note_on with zero velocity is note_off > > if(thisByte == 0 || runningStatus == NOTE_OFF) > > setLed(NOTE_OFF); > > else > > setLed(NOTE_ON); > > } > > else > > thisByte = nextByte(); > > } > > > > Lee > > > > > > -- > > -- From taybin at earthlink.net Wed Jul 26 00:45:55 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Wed Jul 26 00:45:29 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060714064813.9cc0cab1.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> Message-ID: <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo wrote: > > I have for some time been looking for someone to write a > lightweight C++ wrapper for libsndfile that I can distribute > with libsndfile. > > My own rather feeble first attempt is here: > > http://www.mega-nerd.com/tmp/sndfile.hh > > but I am not a fan nor a great user of C++. The wrapper should > really be written by someone with a love for the language. I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I prefer lower case method names, but that's about it. Taybin From mle+la at mega-nerd.com Wed Jul 26 01:07:13 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jul 26 01:07:28 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> Message-ID: <20060726150713.2d0fe787.mle+la@mega-nerd.com> Taybin Rutkin wrote: > On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo wrote: > > > > > I have for some time been looking for someone to write a > > lightweight C++ wrapper for libsndfile that I can distribute > > with libsndfile. > > > > My own rather feeble first attempt is here: > > > > http://www.mega-nerd.com/tmp/sndfile.hh > > > > but I am not a fan nor a great user of C++. The wrapper should > > really be written by someone with a love for the language. > > I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I > prefer lower case method names, but that's about it. Oh, cool, a response at last :-). Well first off, it isn't quite complete and it hasn't been properly tested either. Secondly, with regard to the method names, which do you prefer: - OpenRead - openRead - open_read - something else Since you're the only person who actually responded to the real meat of my email, I have to assume that you are the only person on this list with a love for C++ and hence the only one who should have any real input on this issue ;-). And what you and I come up with the Windiots will have to live with :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham From kauppi at papupata.org Wed Jul 26 02:51:26 2006 From: kauppi at papupata.org (Ari Kauppi) Date: Wed Jul 26 02:51:39 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: On Wed, 26 Jul 2006, Jens M Andreasen wrote: > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) If you plan to receive messages from other channels than 0 you have to use (runningStatus & 0xF0) instead of the full runningStatus and perhaps check for (runningStaus & 0x0F) == receiveChannel.. -- Ari From clemens at ladisch.de Wed Jul 26 03:58:24 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Wed Jul 26 04:01:30 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060726075824.GD3861@turing.informatik.uni-halle.de> Ari Kauppi wrote: > On Wed, 26 Jul 2006, Jens M Andreasen wrote: > > > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) > > If you plan to receive messages from other channels than 0 you have to > use (runningStatus & 0xF0) instead of the full runningStatus and perhaps > check for (runningStaus & 0x0F) == receiveChannel.. Okay, here is my entry to the Official LAD MIDI Parser Contest 2006: void handleByte(u8 byte) { /* in a driver, these static variables should go into some struct: */ static enum { STATE_UNKNOWN, /* not a note command */ STATE_NOTE1, /* expecting 1st data byte (note) */ STATE_NOTE2, /* expecting 2nd data byte (velocity) */ } state = STATE_UNKNOWN; static u8 command; static u8 note; if (byte >= 0xf8) /* real-time command */ ; else if (byte & 0x80) { /* status byte */ command = byte; /* note-on or note-off? */ state = (byte & 0xf0) <= 0x90 ? STATE_NOTE1 : STATE_UNKNOWN; } else { /* data byte */ if (state == STATE_NOTE1) { note = byte; state = STATE_NOTE2; } else if (state == STATE_NOTE2) { if ((command & 0xf0) == 0x90 && byte > 0) { /* note on */ } else { /* note off */ } state = STATE_NOTE1; } } } Regards, Clemens From jonobacon at gmail.com Wed Jul 26 06:04:47 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Wed Jul 26 06:04:54 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? Message-ID: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> Hi all, I am working on LADSPA support in Jokosher and we want Jokosher to depend on particular plug-ins in different parts of the application. Specifically, I would like to see a powerful compressor and equalizer as part of the application. So, my question to you all is which compressor and equalizer do we depend on? Importantly, the chosen plug-ins need to exhibit the following qualities: * packages for all major distributions (Ubuntu, Debian, Red Hat, Fedora, Gentoo, SuSE etc.) * well maintained * very high quality audio quality Cheers, Jono From mista.tapas at gmx.net Wed Jul 26 06:12:35 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Wed Jul 26 06:12:45 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726150713.2d0fe787.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> Message-ID: <20060726121235.75419364@mango.fruits> On Wed, 26 Jul 2006 15:07:13 +1000 Erik de Castro Lopo wrote: > > > My own rather feeble first attempt is here: > > > > > > http://www.mega-nerd.com/tmp/sndfile.hh > > > > > > but I am not a fan nor a great user of C++. The wrapper should > > > really be written by someone with a love for the language. > > > > I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I Well, it is very thin though. Which is not a bad thing at all. One could make ue of an arbitrary amount of more advanced C++ features if desired though (i.e. templates parametrized with the type you want to read for example, or operator<< and operator>> for reading and writing, etc.) > > prefer lower case method names, but that's about it. > > Oh, cool, a response at last :-). > > Well first off, it isn't quite complete and it hasn't been > properly tested either. > > Secondly, with regard to the method names, which do you prefer: > - OpenRead > - openRead > - open_read vote++, i never cared for the more java style methodName convention. > - something else > > Since you're the only person who actually responded to the real > meat of my email, I have to assume that you are the only person > on this list with a love for C++ and hence the only one who > should have any real input on this issue ;-). Nicely worded :) Flo -- Palimm Palimm! http://tapas.affenbande.org From cannam at all-day-breakfast.com Wed Jul 26 06:26:00 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Wed Jul 26 06:25:40 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726121235.75419364@mango.fruits> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> Message-ID: <200607261126.00351.cannam@all-day-breakfast.com> On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: > Well, it is very thin though. Which is not a bad thing at all. One could > make ue of an arbitrary amount of more advanced C++ features if desired > though (i.e. templates parametrized with the type you want to read for > example, or operator<< and operator>> for reading and writing, etc.) operator<< and >>... ugh. > > Secondly, with regard to the method names, which do you prefer: > > > > - OpenRead > > - openRead > > - open_read > > vote++, i never cared for the more java style methodName convention. I think if your class is named LikeThis, then your method should be named likeThat (Java-style). If your method is named like_this, then your class should be named like_that (STL-style). Either is fine, but don't mix your dialects. > > Since you're the only person who actually responded to the real > > meat of my email, I have to assume that you are the only person > > on this list with a love for C++ and hence the only one who > > should have any real input on this issue ;-). > > Nicely worded :) Mmm. For what it's worth, I write mostly C++ but have no problem with using the libsndfile C API. I don't really mind whether it has a C++ API as well or not. So yes, you probably should ignore me. Chris From kauppi at papupata.org Wed Jul 26 06:25:38 2006 From: kauppi at papupata.org (Ari Kauppi) Date: Wed Jul 26 06:26:15 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060726075824.GD3861@turing.informatik.uni-halle.de> References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> <20060726075824.GD3861@turing.informatik.uni-halle.de> Message-ID: On Wed, 26 Jul 2006, Clemens Ladisch wrote: > Ari Kauppi wrote: >> On Wed, 26 Jul 2006, Jens M Andreasen wrote: >> >>> if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) >> >> If you plan to receive messages from other channels than 0 you have to >> use (runningStatus & 0xF0) instead of the full runningStatus and perhaps >> check for (runningStaus & 0x0F) == receiveChannel.. > > Okay, here is my entry to the Official LAD MIDI Parser Contest 2006: Good try but it still has at least one potential problem: according to MIDI spec running status should be set only with channel messages. Sysex/common messages should reset it to undefined (0). With this exact implementation it shouldn't cause any problems but if the parser is extended/modified later it might become a pretty hard to find bug with some input.. > void handleByte(u8 byte) > { > /* in a driver, these static variables should go into some struct: */ > static enum { > STATE_UNKNOWN, /* not a note command */ > STATE_NOTE1, /* expecting 1st data byte (note) */ > STATE_NOTE2, /* expecting 2nd data byte (velocity) */ > } state = STATE_UNKNOWN; > static u8 command; > static u8 note; > > if (byte >= 0xf8) /* real-time command */ > ; > else if (byte & 0x80) { /* status byte */ > command = byte; > /* note-on or note-off? */ > state = (byte & 0xf0) <= 0x90 ? STATE_NOTE1 : STATE_UNKNOWN; > } else { /* data byte */ > if (state == STATE_NOTE1) { > note = byte; > state = STATE_NOTE2; > } else if (state == STATE_NOTE2) { > if ((command & 0xf0) == 0x90 && byte > 0) { > /* note on */ > } else { > /* note off */ > } > state = STATE_NOTE1; > } > } > } -- Ari From mista.tapas at gmx.net Wed Jul 26 06:46:51 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Wed Jul 26 06:47:40 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <200607261126.00351.cannam@all-day-breakfast.com> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> Message-ID: <20060726124651.2bb0d34e@mango.fruits> On Wed, 26 Jul 2006 11:26:00 +0100 Chris Cannam wrote: > > vote++, i never cared for the more java style methodName convention. > > I think if your class is named LikeThis, then your method should be > named likeThat (Java-style). If your method is named like_this, then > your class should be named like_that (STL-style). Either is fine, > but don't mix your dialects. Oh well, this is precisely what i do. For classes i use FooBar. For Objects i use foo_bar. and for methods, it's foo_bar, too. class FooBar { bool _yesno; public: FooBar (bool yesno) : _yesno (yesno) { // ... } void foo_my_bar (bool yesno) { _yesno = yesno; } }; int main () { FooBar foo_bar (false); foo_bar.foo_my_bar (true); } It just strikes some aesthetic nerve in me. And this is something you just cannot argue about. So to each his own i say :) And no, usually i seperate header and implementation, too ;) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From mle+la at mega-nerd.com Wed Jul 26 07:02:31 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jul 26 07:02:56 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <200607261126.00351.cannam@all-day-breakfast.com> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> Message-ID: <20060726210231.7f1dbb44.mle+la@mega-nerd.com> Chris Cannam wrote: > On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: > > Well, it is very thin though. Which is not a bad thing at all. One could > > make ue of an arbitrary amount of more advanced C++ features if desired > > though (i.e. templates parametrized with the type you want to read for > > example, or operator<< and operator>> for reading and writing, etc.) > > operator<< and >>... ugh. Yeah I really gotta agree here. Overloading the left and right shift operators has got to the thing I find most distasteful about C++. > I think if your class is named LikeThis, then your method should be named > likeThat (Java-style). If your method is named like_this, then your class > should be named like_that (STL-style). Either is fine, but don't mix your > dialects. Ok, "don't mix dialects" is a good tip. Most of the proposed methods for the Sndfile class have single word names so Java style might be the best option. > Mmm. For what it's worth, I write mostly C++ but have no problem > with using the libsndfile C API. Most people who really know C++ know enough to be comfortable with pure C. I'm pretty sure you fall into this category. However, I do get emails from some of the more clueless Windiots complaining that libsndfile is written in old-fashioned C instead of nice shiny modern C++. IMNSHO these people should not be allowed anywhere near a language as complex, subtle, and unforgiving as C++ (or for that matter as unforgiving as C). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I consider C++ the most significant technical hazard to the survival of your project and do so without apologies." -- Alistair Cockburn From S.W.Harris at ecs.soton.ac.uk Wed Jul 26 07:08:28 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jul 26 07:10:21 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726210231.7f1dbb44.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> <20060726210231.7f1dbb44.mle+la@mega-nerd.com> Message-ID: <20060726110828.GA403@login.ecs.soton.ac.uk> On Wed, Jul 26, 2006 at 09:02:31 +1000, Erik de Castro Lopo wrote: > > Mmm. For what it's worth, I write mostly C++ but have no problem > > with using the libsndfile C API. > > Most people who really know C++ know enough to be comfortable > with pure C. I'm pretty sure you fall into this category. > > However, I do get emails from some of the more clueless Windiots > complaining that libsndfile is written in old-fashioned C instead > of nice shiny modern C++. IMNSHO these people should not be allowed > anywhere near a language as complex, subtle, and unforgiving as > C++ (or for that matter as unforgiving as C). Heh, I get that from UNIX people too though, I always assumed they were trying to wind me up... - Steve From t_w_ at freenet.de Wed Jul 26 07:20:09 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Wed Jul 26 07:20:17 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> Message-ID: <20060726112009.GB7367@charly.SWORD> On Wed, Jul 26, 2006 at 11:04:47AM +0100, Jono Bacon wrote: > Hi all, > > I am working on LADSPA support in Jokosher and we want Jokosher to > depend on particular plug-ins in different parts of the application. > Specifically, I would like to see a powerful compressor and equalizer > as part of the application. You should not depend on particular plugins, if the app could work without just fine. Hasn't Debian a 'Recommends' thing going for things like this? > So, my question to you all is which compressor and equalizer do we > depend on? The SWH collection from our plugin grandmaster Steve contains the only compressor LADSPAs with sidechain input. I'm pretty sure there's EQing stuff in there, too. -- Thorsten Wilms From lars.luthman at gmail.com Wed Jul 26 07:21:34 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Jul 26 07:22:10 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <200607261126.00351.cannam@all-day-breakfast.com> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> Message-ID: <1153912894.10636.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Wed, 2006-07-26 at 11:26 +0100, Chris Cannam wrote: > On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: > > Well, it is very thin though. Which is not a bad thing at all. One could > > make ue of an arbitrary amount of more advanced C++ features if desired > > though (i.e. templates parametrized with the type you want to read for > > example, or operator<< and operator>> for reading and writing, etc.) > > operator<< and >>... ugh. Operator overloading is lovely. When reading fixed size audio chunks a function call syntax makes more sense though (how else would you specify the chunk size? sndfile>>setw(1024)>>my_buffer is a bit too weird). > > > Secondly, with regard to the method names, which do you prefer: > > > > > > - OpenRead > > > - openRead > > > - open_read > > > > vote++, i never cared for the more java style methodName convention. > > I think if your class is named LikeThis, then your method should be named > likeThat (Java-style). If your method is named like_this, then your class > should be named like_that (STL-style). Either is fine, but don't mix your > dialects. I use ClassNames and function_names all the time. I think it makes it easier to distinguish between them. > > > Since you're the only person who actually responded to the real > > > meat of my email, I have to assume that you are the only person > > > on this list with a love for C++ and hence the only one who > > > should have any real input on this issue ;-). > > > > Nicely worded :) > > Mmm. For what it's worth, I write mostly C++ but have no problem with using > the libsndfile C API. I don't really mind whether it has a C++ API as well > or not. So yes, you probably should ignore me. I agree - the libsndfile API is simple enough to fit into C++ code quite nicely. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/7b3acae6/attachment-0001.bin From taybin at earthlink.net Wed Jul 26 07:22:30 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Wed Jul 26 07:22:23 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726150713.2d0fe787.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> Message-ID: <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> On Jul 26, 2006, at 1:07 AM, Erik de Castro Lopo wrote: > Taybin Rutkin wrote: > >> On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo wrote: >> >>> >>> I have for some time been looking for someone to write a >>> lightweight C++ wrapper for libsndfile that I can distribute >>> with libsndfile. >>> >>> My own rather feeble first attempt is here: >>> >>> http://www.mega-nerd.com/tmp/sndfile.hh >>> >>> but I am not a fan nor a great user of C++. The wrapper should >>> really be written by someone with a love for the language. >> >> I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I >> prefer lower case method names, but that's about it. > > Oh, cool, a response at last :-). > > Well first off, it isn't quite complete and it hasn't been > properly tested either. > > Secondly, with regard to the method names, which do you prefer: > > - OpenRead > - openRead > - open_read I prefer the unix-y open_read(). I don't think method names should ever start with a capital, unless it's the ctor or dtor. > - something else > > Since you're the only person who actually responded to the real > meat of my email, I have to assume that you are the only person > on this list with a love for C++ and hence the only one who > should have any real input on this issue ;-). I noticed that the constructor SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo) isn't declared in the class. Also, since this constructor can fail if sf_open() fails up, it should throw an exception. Maybe containing the results of sf_strerror(). Something like SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo) { psf = sf_open (path, mode, sfinfo) ; if (!psf) { throw sf_error(psf); } } Taybin From lars.luthman at gmail.com Wed Jul 26 07:24:02 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Jul 26 07:24:58 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726110828.GA403@login.ecs.soton.ac.uk> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> <20060726210231.7f1dbb44.mle+la@mega-nerd.com> <20060726110828.GA403@login.ecs.soton.ac.uk> Message-ID: <1153913042.10636.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Wed, 2006-07-26 at 12:08 +0100, Steve Harris wrote: > On Wed, Jul 26, 2006 at 09:02:31 +1000, Erik de Castro Lopo wrote: > > > Mmm. For what it's worth, I write mostly C++ but have no problem > > > with using the libsndfile C API. > > > > Most people who really know C++ know enough to be comfortable > > with pure C. I'm pretty sure you fall into this category. > > > > However, I do get emails from some of the more clueless Windiots > > complaining that libsndfile is written in old-fashioned C instead > > of nice shiny modern C++. IMNSHO these people should not be allowed > > anywhere near a language as complex, subtle, and unforgiving as > > C++ (or for that matter as unforgiving as C). > > Heh, I get that from UNIX people too though, I always assumed they were > trying to wind me up... But it _would_ be nice to have template functors as callbacks in liblo, so you wouldn't have to write static wrappers all the time. =) -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/c7260433/attachment.bin From mle+la at mega-nerd.com Wed Jul 26 07:52:27 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jul 26 07:52:39 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> Message-ID: <20060726215227.1727b94c.mle+la@mega-nerd.com> Taybin Rutkin wrote: > I prefer the unix-y open_read(). I don't think method names should > ever start with a capital, unless it's the ctor or dtor. I'm actually tending towards openRead(). > I noticed that the constructor SndFile::SndFile (const char *path, > int mode, SF_INFO *sfinfo) > isn't declared in the class. Also, since this constructor can fail > if sf_open() fails up, it should throw an exception. Maybe > containing the results of sf_strerror(). > > Something like > > SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo) > { > psf = sf_open (path, mode, sfinfo) ; > if (!psf) { > throw sf_error(psf); > } > } Good tip, thanks. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill From jens.andreasen at chello.se Wed Jul 26 07:56:20 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Jul 26 07:56:29 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: References: <1153773537.25859.114.camel@mindpipe> <1153774635.11063.4.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1153914980.9274.934.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-07-26 at 09:51 +0300, Ari Kauppi wrote: > On Wed, 26 Jul 2006, Jens M Andreasen wrote: > > > if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF) > > If you plan to receive messages from other channels than 0 you have to > use (runningStatus & 0xF0) instead of the full runningStatus and perhaps > check for (runningStaus & 0x0F) == receiveChannel.. Thanx! In this case I think we can get by without increasing instruction count, like this: if((runningStatus - NOTE_OFF) < 0x20) // note_on or note_off { ... and keep switch(runningStatus & 0xF0) in mind for an extension. The receive channel is better handled in the note on/off function(s). There can be all kinds of differences between channels that the parser need not to have any knowledge of. If this is going to be some kind of Official Blinking Light Parser Contest, I better do an explicit rewrite so it can compile :-) Those who chip in, get to share the prize! -- From fons.adriaensen at alcatelaleniaspace.com Wed Jul 26 08:06:50 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jul 26 08:07:01 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: References: <1153775343.25859.125.camel@mindpipe> <20060725090356.GC23978@turing.informatik.uni-halle.de> <1153837594.25859.191.camel@mindpipe> <1153846397.9274.854.camel@c80-216-124-251.cm-upc.chello.se> <1153846854.9274.858.camel@c80-216-124-251.cm-upc.chello.se> <20060725195532.GE14390@localhost> <1153871733.9274.904.camel@c80-216-124-251.cm-upc.chello.se> <20060726075824.GD3861@turing.informatik.uni-halle.de> Message-ID: <20060726120650.GE15550@bth05w.ABSp.alcatel.be> On Wed, Jul 26, 2006 at 01:25:38PM +0300, Ari Kauppi wrote: > Good try but it still has at least one potential problem: according to > MIDI spec running status should be set only with channel messages. > Sysex/common messages should reset it to undefined (0). I don't have a midi spec at hand here. Do you mean running status is shared by all channels and not per channel ? This would make it less than trivial to combine or split midi streams. Say chan 1 has set RS to some value, and the next command on this channel doesn't have a status byte but uses the RS. Now we merge in a second channel that modifies RS in between the two commands on chan 1. Suddenly the second one of those _does_ need a status byte... -- FA Lascia la spina, cogli la rosa. From cannam at all-day-breakfast.com Wed Jul 26 08:16:27 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Wed Jul 26 08:16:04 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <20060726120650.GE15550@bth05w.ABSp.alcatel.be> References: <1153775343.25859.125.camel@mindpipe> <20060726120650.GE15550@bth05w.ABSp.alcatel.be> Message-ID: <200607261316.27834.cannam@all-day-breakfast.com> On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen wrote: > I don't have a midi spec at hand here. Do you mean running status > is shared by all channels and not per channel ? This would make > it less than trivial to combine or split midi streams. The channel is part of the status byte. Chris From fons.adriaensen at alcatelaleniaspace.com Wed Jul 26 08:59:10 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Wed Jul 26 08:59:28 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <200607261316.27834.cannam@all-day-breakfast.com> References: <1153775343.25859.125.camel@mindpipe> <20060726120650.GE15550@bth05w.ABSp.alcatel.be> <200607261316.27834.cannam@all-day-breakfast.com> Message-ID: <20060726125909.GF15550@bth05w.ABSp.alcatel.be> On Wed, Jul 26, 2006 at 01:16:27PM +0100, Chris Cannam wrote: > The channel is part of the status byte. Yes, of course. It's really too hot here. -- FA Lascia la spina, cogli la rosa. From kauppi at papupata.org Wed Jul 26 09:18:58 2006 From: kauppi at papupata.org (Ari Kauppi) Date: Wed Jul 26 09:19:14 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: <200607261316.27834.cannam@all-day-breakfast.com> References: <1153775343.25859.125.camel@mindpipe> <20060726120650.GE15550@bth05w.ABSp.alcatel.be> <200607261316.27834.cannam@all-day-breakfast.com> Message-ID: On Wed, 26 Jul 2006, Chris Cannam wrote: > On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen wrote: >> I don't have a midi spec at hand here. Do you mean running status >> is shared by all channels and not per channel ? This would make >> it less than trivial to combine or split midi streams. > > The channel is part of the status byte. Yep. Channel message means MIDI events with status byte 0x80 - 0xEF. For status bytes 0xF0 - 0xFF running status should not be used and the internal running status buffer should be cleared. -- Ari From b0ef at esben-stien.name Wed Jul 26 11:25:08 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Jul 26 09:34:10 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> (Jono Bacon's message of "Wed, 26 Jul 2006 11:04:47 +0100") References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> Message-ID: <87vepkwfqj.fsf@esben-stien.name> "Jono Bacon" writes: > want Jokosher to depend on particular plug-ins Talk about virtual limitation;). -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@ n n From richard.spindler at gmail.com Wed Jul 26 09:41:24 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Wed Jul 26 09:41:49 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <20060726112009.GB7367@charly.SWORD> References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> <20060726112009.GB7367@charly.SWORD> Message-ID: <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> 2006/7/26, Thorsten Wilms : > You should not depend on particular plugins, if the app could work > without just fine. Hasn't Debian a 'Recommends' thing going for > things like this? Doesn't JAMin need the SWH Plugins for it's equalizer and stuff? Therefore it seems as if it's "dependent" on these plugins. So it shouldn't be a problem for Jokosher to take the same approach. -- Are you teaching the What and the How but without the Why and the When? From jonobacon at gmail.com Wed Jul 26 10:08:43 2006 From: jonobacon at gmail.com (Jono Bacon) Date: Wed Jul 26 10:09:04 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> <20060726112009.GB7367@charly.SWORD> <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> Message-ID: <1c3fe48e0607260708u9d53c8at206691da28cfd081@mail.gmail.com> Hi all, The point of depending on certain plug-ins is so we can guarantee certain functionality, namely compression and EQ. It will of course allow additional LADSPA plug-in to be installed and used. :) Jono From S.W.Harris at ecs.soton.ac.uk Wed Jul 26 10:30:35 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jul 26 10:30:56 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> <20060726112009.GB7367@charly.SWORD> <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> Message-ID: <20060726143035.GC403@login.ecs.soton.ac.uk> On Wed, Jul 26, 2006 at 03:41:24PM +0200, Richard Spindler wrote: > 2006/7/26, Thorsten Wilms : > >You should not depend on particular plugins, if the app could work > >without just fine. Hasn't Debian a 'Recommends' thing going for > >things like this? > > Doesn't JAMin need the SWH Plugins for it's equalizer and stuff? > Therefore it seems as if it's "dependent" on these plugins. Yes, it does. > So it shouldn't be a problem for Jokosher to take the same approach. Sure. It's better than code duplication in my opinion. - Steve From jens.andreasen at chello.se Wed Jul 26 10:38:34 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Jul 26 10:38:46 2006 Subject: [linux-audio-dev] Basic MIDI question In-Reply-To: References: <1153775343.25859.125.camel@mindpipe> <20060726120650.GE15550@bth05w.ABSp.alcatel.be> <200607261316.27834.cannam@all-day-breakfast.com> Message-ID: <1153924714.9274.946.camel@c80-216-124-251.cm-upc.chello.se> On Wed, 2006-07-26 at 16:18 +0300, Ari Kauppi wrote: > On Wed, 26 Jul 2006, Chris Cannam wrote: > > > On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen wrote: > >> I don't have a midi spec at hand here. Do you mean running status > >> is shared by all channels and not per channel ? This would make > >> it less than trivial to combine or split midi streams. > > > > The channel is part of the status byte. > > Yep. Channel message means MIDI events with status byte 0x80 - 0xEF. For > status bytes 0xF0 - 0xFF running status should not be used and the > internal running status buffer should be cleared. > You meant to say: For status bytes 0xF0 - 0xF7 running status should be cleared. For 0xF8 - 0xFF (single byte SysRt) it should be maintained. Isn't the status implicitly cleared if you set it to, say 0xF0? Which is to say that it is the SysRt exceptions that matters. Who said it was hot today? -- From dsbaikov at gmail.com Wed Jul 26 13:32:34 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed Jul 26 13:32:53 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726215227.1727b94c.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> <20060726215227.1727b94c.mle+la@mega-nerd.com> Message-ID: <70a871c80607261032g26f31ba8l659b0c25fe36c6c4@mail.gmail.com> Hi, Erik! I'd suggest making all wrapper functions inline, as they are one-liners by definition and anyway wrapper includes libsndfile headers. So there's nothing to hide here. Regards, Dmitry From pcoccoli at gmail.com Wed Jul 26 14:03:40 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Jul 26 14:04:13 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060726215227.1727b94c.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> <20060726215227.1727b94c.mle+la@mega-nerd.com> Message-ID: <8d27a0610607261103r653d692ahf04d4100153017e7@mail.gmail.com> On 7/26/06, Erik de Castro Lopo wrote: > Taybin Rutkin wrote: > > > I prefer the unix-y open_read(). I don't think method names should > > ever start with a capital, unless it's the ctor or dtor. > > I'm actually tending towards openRead(). > I vote for Java (SmallTalk?) style too. > > I noticed that the constructor SndFile::SndFile (const char *path, > > int mode, SF_INFO *sfinfo) > > isn't declared in the class. Also, since this constructor can fail > > if sf_open() fails up, it should throw an exception. Maybe > > containing the results of sf_strerror(). > > > > Something like > > > > SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo) > > { > > psf = sf_open (path, mode, sfinfo) ; > > if (!psf) { > > throw sf_error(psf); > > } > > } > > Good tip, thanks. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > "If you think C++ is not overly complicated, just what is a > protected abstract virtual base pure virtual private destructor > and when was the last time you needed one?" -- Tom Cargill > I wouldn't bother with openRead/Write; just pass the mode in to open like in the ctor. I also second keeping the implementation entirely in the header (if it really is a light wrapper) and put "inline" in front of each method definition. SndFile::strerror() should maybe take an int arg (the value returned by SndFile::error()) and be declared as a static method? From pcoccoli at gmail.com Wed Jul 26 14:06:55 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Jul 26 14:07:02 2006 Subject: [linux-audio-dev] Popular LADSPA plug-ins to depend on? In-Reply-To: <20060726143035.GC403@login.ecs.soton.ac.uk> References: <1c3fe48e0607260304i3f48dd34n61626a5f829b64f1@mail.gmail.com> <20060726112009.GB7367@charly.SWORD> <4af8d6ff0607260641k3200f083o4a59052ea57b0f99@mail.gmail.com> <20060726143035.GC403@login.ecs.soton.ac.uk> Message-ID: <8d27a0610607261106y55c97333p7a85ad1c0b36276b@mail.gmail.com> On 7/26/06, Steve Harris wrote: > On Wed, Jul 26, 2006 at 03:41:24PM +0200, Richard Spindler wrote: > > 2006/7/26, Thorsten Wilms : > > >You should not depend on particular plugins, if the app could work > > >without just fine. Hasn't Debian a 'Recommends' thing going for > > >things like this? > > > > Doesn't JAMin need the SWH Plugins for it's equalizer and stuff? > > Therefore it seems as if it's "dependent" on these plugins. > > Yes, it does. > > > So it shouldn't be a problem for Jokosher to take the same approach. > > Sure. It's better than code duplication in my opinion. > > - Steve > Running a mastering app without compression and EQ would be kind of silly. I wouldn't say the same thing about a recording app, since the plugins are only used on playback and export. From kouhia at nic.funet.fi Wed Jul 26 14:15:08 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Wed Jul 26 14:15:31 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project Message-ID: >From: Renich Bon ?iri? > And what you wanted to say? The mail had no content. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From renich at woralelandia.com Wed Jul 26 15:03:00 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Wed Jul 26 15:03:13 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: References: Message-ID: <44C7BC64.20204@woralelandia.com> Well, we are trying to make a proposal to Akai Pro so it releases the source code of the OS that runs on the MPC4000 Worstation/Sampler. If you want to join and help, go to http://www.woralelandia.com/openmpc/ # Reference http://www.mpc-forums.com/viewtopic.php?t=54825 Juhana Sadeharju wrote: >> From: Renich Bon ?iri? >> >> > > And what you wanted to say? The mail had no content. > > Juhana > -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/5a2422ef/renich.vcf From mle+la at mega-nerd.com Wed Jul 26 16:45:46 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jul 26 16:46:00 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <8d27a0610607261103r653d692ahf04d4100153017e7@mail.gmail.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> <20060726215227.1727b94c.mle+la@mega-nerd.com> <8d27a0610607261103r653d692ahf04d4100153017e7@mail.gmail.com> Message-ID: <20060727064546.ce81a45e.mle+la@mega-nerd.com> Paul Coccoli wrote: > I wouldn't bother with openRead/Write; just pass the mode in to open > like in the ctor. The open/close methods are provided so a single Sndfile object can be opened and closed multiple times. I was also going to make the copy constructor and asignment operator private so they can't be misused. > I also second keeping the implementation entirely in the header (if it > really is a light wrapper) and put "inline" in front of each method > definition. Thats was the idea from the start. I light-weight wrapper. > SndFile::strerror() should maybe take an int arg (the value returned > by SndFile::error()) and be declared as a static method? Good catch. Thanks. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "To me C++ seems to be a language that has sacrificed orthogonality and elegance for random expediency." -- Meilir Page-Jones From mle+la at mega-nerd.com Wed Jul 26 16:58:32 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jul 26 16:58:43 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <70a871c80607261032g26f31ba8l659b0c25fe36c6c4@mail.gmail.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> <20060726215227.1727b94c.mle+la@mega-nerd.com> <70a871c80607261032g26f31ba8l659b0c25fe36c6c4@mail.gmail.com> Message-ID: <20060727065832.bac0d658.mle+la@mega-nerd.com> Dmitry Baikov wrote: > Hi, Erik! > > I'd suggest making all wrapper functions inline, > as they are one-liners by definition and > anyway wrapper includes libsndfile headers. > So there's nothing to hide here. Yes, that was my idea. So if the sndfile.hh has: class Sndile { int method (/* params */) ; } int method (/* params */) { /* whatever */ } do I need to add an inline keyword anywhere and if so where? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "It has been discovered that C++ provides a remarkable facility for concealing the trival details of a program -- such as where its bugs are." -- David Keppel From fons.adriaensen at skynet.be Wed Jul 26 17:26:49 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Jul 26 17:25:58 2006 Subject: [linux-audio-dev] light C++ set for WAV In-Reply-To: <20060727065832.bac0d658.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060713180744.GA5943@linux-1.site> <20060714064813.9cc0cab1.mle+la@mega-nerd.com> <7CABF4AD-9902-4996-80B8-C9EE7C786787@earthlink.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <28B8244C-85FC-4838-99BD-2BC4FEFA8F2B@earthlink.net> <20060726215227.1727b94c.mle+la@mega-nerd.com> <70a871c80607261032g26f31ba8l659b0c25fe36c6c4@mail.gmail.com> <20060727065832.bac0d658.mle+la@mega-nerd.com> Message-ID: <20060726212649.GB7837@linux-1.site> On Thu, Jul 27, 2006 at 06:58:32AM +1000, Erik de Castro Lopo wrote: > Yes, that was my idea. So if the sndfile.hh has: > > class Sndile > { > int method (/* params */) ; > } > > int method (/* params */) > { > /* whatever */ > } > > do I need to add an inline keyword anywhere and if so where? You need either class Sndfile { int method (/* params */) ; }; // note the ; inline int Sndfile::method (/* params */) { /* whatever */ } or class Sndfile { int method (/* params */) { /* whatever */ } }; I use the second form often if the function body is trivial e.g. just one statement, as for a getter / setter. -- FA Lascia la spina, cogli la rosa. From mobarre at gmail.com Wed Jul 26 18:26:21 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Wed Jul 26 18:26:28 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C7BC64.20204@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> Message-ID: <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> On 7/26/06, Renich Bon ?iri? wrote: > Well, we are trying to make a proposal to Akai Pro so it releases the > source code of the OS that runs on the MPC4000 Worstation/Sampler. > > If you want to join and help, go to http://www.woralelandia.com/openmpc/ > > # Reference > http://www.mpc-forums.com/viewtopic.php?t=54825 > I took a look at the specs Akai sent you. If you intend to port linux to it, you have a nice begining there. You have the full list of hardware pieces inside, and all the schematics. Even if akai don't give you their OS source, everything is still possible. -- Marc-Olivier Barre. From renich at woralelandia.com Wed Jul 26 18:29:45 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Wed Jul 26 18:29:58 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> Message-ID: <44C7ECD9.6060500@woralelandia.com> Thank you so much for the those words! ;=) As you saw at the links, the first goal is to get the source from Akai... even a beta. If that fails, we are gonna try and develop a whole OS. Thanks again Marc-Olivier Barre wrote: > On 7/26/06, Renich Bon ?iri? wrote: >> Well, we are trying to make a proposal to Akai Pro so it releases the >> source code of the OS that runs on the MPC4000 Worstation/Sampler. >> >> If you want to join and help, go to http://www.woralelandia.com/openmpc/ >> >> # Reference >> http://www.mpc-forums.com/viewtopic.php?t=54825 >> > > I took a look at the specs Akai sent you. If you intend to port linux > to it, you have a nice begining there. You have the full list of > hardware pieces inside, and all the schematics. Even if akai don't > give you their OS source, everything is still possible. > -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/fcb47c48/renich.vcf From rlrevell at joe-job.com Wed Jul 26 18:41:13 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jul 26 18:41:23 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C7ECD9.6060500@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> Message-ID: <1153953674.2927.24.camel@mindpipe> On Wed, 2006-07-26 at 17:29 -0500, Renich Bon ?iri? wrote: > Thank you so much for the those words! ;=) > > As you saw at the links, the first goal is to get the source from > Akai... even a beta. If that fails, we are gonna try and develop a whole OS. > Why? That makes no sense. Why not just port Linux to it? > Thanks again > > Marc-Olivier Barre wrote: > > On 7/26/06, Renich Bon ?iri? wrote: > >> Well, we are trying to make a proposal to Akai Pro so it releases the > >> source code of the OS that runs on the MPC4000 Worstation/Sampler. > >> > >> If you want to join and help, go to http://www.woralelandia.com/openmpc/ > >> > >> # Reference > >> http://www.mpc-forums.com/viewtopic.php?t=54825 > >> > > > > I took a look at the specs Akai sent you. If you intend to port linux > > to it, you have a nice begining there. You have the full list of > > hardware pieces inside, and all the schematics. Even if akai don't > > give you their OS source, everything is still possible. > > From renich at woralelandia.com Wed Jul 26 18:51:50 2006 From: renich at woralelandia.com (=?ISO-8859-2?Q?Renich_Bon_=C6iri=E6?=) Date: Wed Jul 26 18:52:06 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1153953674.2927.24.camel@mindpipe> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> Message-ID: <44C7F206.4030100@woralelandia.com> Well, everybody's telling me that Akai's OS is something else. Realtime stuff and 2 or 3 engines and DSPs to manage. Besides, we have to support akai's native file formats, like PROGRAM, MULTI and Sequence. I really don't know why... I'm just hearing what everybody says. You think it shouldn't be that hard to port Linux and develop the effects and stuff, and to support Akai's native format? Would you give me some arguments and reasons? Thanks for the input! Lee Revell wrote: > On Wed, 2006-07-26 at 17:29 -0500, Renich Bon ?iri? wrote: > >> Thank you so much for the those words! ;=) >> >> As you saw at the links, the first goal is to get the source from >> Akai... even a beta. If that fails, we are gonna try and develop a whole OS. >> >> > > Why? That makes no sense. Why not just port Linux to it? > > >> Thanks again >> >> Marc-Olivier Barre wrote: >> >>> On 7/26/06, Renich Bon ?iri? wrote: >>> >>>> Well, we are trying to make a proposal to Akai Pro so it releases the >>>> source code of the OS that runs on the MPC4000 Worstation/Sampler. >>>> >>>> If you want to join and help, go to http://www.woralelandia.com/openmpc/ >>>> >>>> # Reference >>>> http://www.mpc-forums.com/viewtopic.php?t=54825 >>>> >>>> >>> I took a look at the specs Akai sent you. If you intend to port linux >>> to it, you have a nice begining there. You have the full list of >>> hardware pieces inside, and all the schematics. Even if akai don't >>> give you their OS source, everything is still possible. >>> >>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 378 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/e1cebc56/renich-0001.vcf From mobarre at gmail.com Wed Jul 26 18:57:07 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Wed Jul 26 18:57:15 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1153953674.2927.24.camel@mindpipe> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> Message-ID: <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> > Why? That makes no sense. Why not just port Linux to it? Agreed. There are so many embeded linux projects out there, it would be like writing one's own printf function when there's glibc here to do the job... Moreover, it would allow you to take avantage of a lot of application/file formats/whatever that is working already pretty well on a linux audio workstation. Looking at the specs, the MPC 4000 seems like a big pack of knobs, LCDs, LEDs, and audio circuits. it's up to the OS to do some music with it. Are you sure you want to go on the crusade of reinventing not only the wheel, but also the whole stuff around it ? ________________ Marc-Olivier Barre, Kinoko en Orbite. From renich at woralelandia.com Wed Jul 26 19:00:59 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Wed Jul 26 19:01:14 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> Message-ID: <44C7F42B.6030200@woralelandia.com> Well, very wise words you say. But, on the other hand, this piece of hardware is worth 3,000 usd. We have a ton of users to think about. We must provide compatibility with it's native format. It would be cool to be able to use all the OpenSource arsenal out there. But first, we need to clone... at least, that's what they have said (the users) Marc-Olivier Barre wrote: >> Why? That makes no sense. Why not just port Linux to it? > > Agreed. There are so many embeded linux projects out there, it would > be like writing one's own printf function when there's glibc here to > do the job... > > Moreover, it would allow you to take avantage of a lot of > application/file formats/whatever that is working already pretty well > on a linux audio workstation. > > Looking at the specs, the MPC 4000 seems like a big pack of knobs, > LCDs, LEDs, and audio circuits. it's up to the OS to do some music > with it. Are you sure you want to go on the crusade of reinventing not > only the wheel, but also the whole stuff around it ? > > ________________ > Marc-Olivier Barre, > Kinoko en Orbite. -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/d07df774/renich.vcf From loki.davison at gmail.com Wed Jul 26 19:06:27 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Jul 26 19:06:45 2006 Subject: [linux-audio-dev] Re: light C++ set for WAV In-Reply-To: <20060726210231.7f1dbb44.mle+la@mega-nerd.com> References: <200607132156.58993@goldspace.net> <20060726150713.2d0fe787.mle+la@mega-nerd.com> <20060726121235.75419364@mango.fruits> <200607261126.00351.cannam@all-day-breakfast.com> <20060726210231.7f1dbb44.mle+la@mega-nerd.com> Message-ID: On 7/26/06, Erik de Castro Lopo wrote: > Chris Cannam wrote: > > > On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: > > > Well, it is very thin though. Which is not a bad thing at all. One could > > > make ue of an arbitrary amount of more advanced C++ features if desired > > > though (i.e. templates parametrized with the type you want to read for > > > example, or operator<< and operator>> for reading and writing, etc.) > > > > operator<< and >>... ugh. > > Yeah I really gotta agree here. Overloading the left and right > shift operators has got to the thing I find most distasteful > about C++. > > > I think if your class is named LikeThis, then your method should be named > > likeThat (Java-style). If your method is named like_this, then your class > > should be named like_that (STL-style). Either is fine, but don't mix your > > dialects. > > Ok, "don't mix dialects" is a good tip. Most of the proposed methods > for the Sndfile class have single word names so Java style might be > the best option. > > > Mmm. For what it's worth, I write mostly C++ but have no problem > > with using the libsndfile C API. > > Most people who really know C++ know enough to be comfortable > with pure C. I'm pretty sure you fall into this category. > > However, I do get emails from some of the more clueless Windiots > complaining that libsndfile is written in old-fashioned C instead > of nice shiny modern C++. IMNSHO these people should not be allowed > anywhere near a language as complex, subtle, and unforgiving as > C++ (or for that matter as unforgiving as C). > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > "I consider C++ the most significant technical hazard to the survival > of your project and do so without apologies." -- Alistair Cockburn > Are you sure these people should be let near a computer, less alone a complex, subtle and unforgiving language? ;) I still love your sig messages.... ;) Loki -- "If once a man indulges himself in murder, very soon he comes to think little of robbing; and from robbing he next comes to drinking and Sabbath-breaking, and from that to incivility and procrastination." -- Thomas De Quincey (1785 - 1859) From rlrevell at joe-job.com Wed Jul 26 19:07:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jul 26 19:08:18 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C7F42B.6030200@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> Message-ID: <1153955262.2927.29.camel@mindpipe> On Wed, 2006-07-26 at 18:00 -0500, Renich Bon ?iri? wrote: > Well, very wise words you say. But, on the other hand, this piece of > hardware is worth 3,000 usd. We have a ton of users to think about. We > must provide compatibility with it's native format. > > It would be cool to be able to use all the OpenSource arsenal out there. > But first, we need to clone... at least, that's what they have said (the > users) > Just port Linux to it then develop the support for the native file systems/formats/etc. MUCH less work than writing your own OS. (BTW top posting is considered bad form on this list) It sounds like you're responding to user requests of some kind - do you have a link? What exactly are you trying to accomplish? Lee From mobarre at gmail.com Wed Jul 26 19:09:58 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Wed Jul 26 19:10:05 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C7F42B.6030200@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> Message-ID: <3c808a150607261609i23d6644btfb9697f473f2b1ba@mail.gmail.com> On 7/27/06, Renich Bon ?iri? wrote: > Well, very wise words you say. But, on the other hand, this piece of > hardware is worth 3,000 usd. We have a ton of users to think about. We > must provide compatibility with it's native format. > > It would be cool to be able to use all the OpenSource arsenal out there. > But first, we need to clone... at least, that's what they have said (the > users) Sure, cloning must also be part of the deal. I was also thinking of extending the possibilities of the beast while also supporting the current formats used. If you have to concentrate your efforts of negociations with Akai on something, let it be the full specs of their formats (or maybe it has already been given ?) The things you might lack if choosing linux are file format support, and eventually some driver stuff. This is such a small part of an operating system... compared to all the other stuff you would have to create if you intend to build one from scratch. _________________ Marc-Olivier Barre, Kinoko en Orbite. From renich at woralelandia.com Thu Jul 27 00:31:16 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 00:31:29 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <3c808a150607261609i23d6644btfb9697f473f2b1ba@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> <3c808a150607261609i23d6644btfb9697f473f2b1ba@mail.gmail.com> Message-ID: <44C84194.9040800@woralelandia.com> What is top Posting? Well anyway, I do have some links. # The forum where it all started http://www.mpc-forums.com/viewtopic.php?t=54825 # The site I've established to make this happen. http://www.woralelandia.com/openmpc I could use all the help available. Thank you so much for all your support and advice. I will seriously consider Linux if we're gonna develop an OS. Marc-Olivier Barre wrote: > On 7/27/06, Renich Bon ?iri? wrote: >> Well, very wise words you say. But, on the other hand, this piece of >> hardware is worth 3,000 usd. We have a ton of users to think about. We >> must provide compatibility with it's native format. >> >> It would be cool to be able to use all the OpenSource arsenal out there. >> But first, we need to clone... at least, that's what they have said (the >> users) > > Sure, cloning must also be part of the deal. I was also thinking of > extending the possibilities of the beast while also supporting the > current formats used. If you have to concentrate your efforts of > negociations with Akai on something, let it be the full specs of their > formats (or maybe it has already been given ?) > > The things you might lack if choosing linux are file format support, > and eventually some driver stuff. This is such a small part of an > operating system... compared to all the other stuff you would have to > create if you intend to build one from scratch. > > _________________ > Marc-Olivier Barre, > Kinoko en Orbite. -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/d9524015/renich.vcf From renich at woralelandia.com Thu Jul 27 00:47:38 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 00:47:53 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1153955262.2927.29.camel@mindpipe> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> <1153955262.2927.29.camel@mindpipe> Message-ID: <44C8456A.6050208@woralelandia.com> Lee Revell wrote: > It sounds like you're responding to user requests of some kind - do you > have a link? What exactly are you trying to accomplish? > > Lee > I am trying to help akai give the user community a bug-free, better OS for us to be able to make great music; learn in the way and help. That is what I want. One question, is this still top posting? -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060726/9a435402/renich-0001.vcf From jens.andreasen at chello.se Thu Jul 27 03:12:00 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jul 27 03:12:13 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C84194.9040800@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> <3c808a150607261609i23d6644btfb9697f473f2b1ba@mail.gmail.com> <44C84194.9040800@woralelandia.com> Message-ID: <1153984320.9274.953.camel@c80-216-124-251.cm-upc.chello.se> The answer is 42, but nobody knows the question ... On Wed, 2006-07-26 at 23:31 -0500, Renich Bon ?iri? wrote: > What is top Posting? Well anyway [...] Ahh! Top Posting is to inverse the normal flow of conversation, putting the latest input first. Can work out sometimes, but most often not. From mobarre at gmail.com Thu Jul 27 05:02:47 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Thu Jul 27 05:02:56 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8456A.6050208@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <3c808a150607261557y862d016ida0be3e259d28347@mail.gmail.com> <44C7F42B.6030200@woralelandia.com> <1153955262.2927.29.camel@mindpipe> <44C8456A.6050208@woralelandia.com> Message-ID: <3c808a150607270202h6bd101d7id767ed3dc67afbf2@mail.gmail.com> On 7/27/06, Renich Bon ?iri? wrote: > Lee Revell wrote: > > It sounds like you're responding to user requests of some kind - do you > > have a link? What exactly are you trying to accomplish? > > > > Lee > > > I am trying to help akai give the user community a bug-free, better OS > for us to be able to make great music; learn in the way and help. That > is what I want. One question, is this still top posting? Nope, your post was in the right order this time :-) Your answer has to be after the previous email in the conversation. Just like when you write, the story goes from the top of the page to the bottom. cheers, ______________ Marc-Olivier Barre, Kinoko en Orbite. From James at superbug.co.uk Thu Jul 27 06:10:34 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Jul 27 06:10:41 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C7F206.4030100@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> Message-ID: <44C8911A.3000604@superbug.co.uk> Renich Bon ?iri? wrote: > Well, everybody's telling me that Akai's OS is something else. > Realtime stuff and 2 or 3 engines and DSPs to manage. Besides, we have > to support akai's native file formats, like PROGRAM, MULTI and Sequence. > > I really don't know why... I'm just hearing what everybody says. You > think it shouldn't be that hard to port Linux and develop the effects > and stuff, and to support Akai's native format? Would you give me some > arguments and reasons? > > Thanks for the input! The datasheet you posted it nice a detailed. We would need documentation regarding the file formats, so we could implement support for them. I think the biggest problem you will come up against will be getting the equipment and the open source developers together. Unless you donate the kit to each developer, nothing will happen. The kit is far too expensive for a developer to purchase out of good will. James From renich at woralelandia.com Thu Jul 27 09:51:23 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 09:51:47 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8911A.3000604@superbug.co.uk> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> Message-ID: <44C8C4DB.1090800@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060727/fd285709/renich.vcf From pshirkey at boosthardware.com Thu Jul 27 10:02:09 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Thu Jul 27 10:03:09 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8C4DB.1090800@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> Message-ID: <44C8C761.1070900@boosthardware.com> Renich Bon C'iric' wrote: > >> Linux as it is ordinarily distributed is not a small-footprint >> real-time operating system. Partly true. Depends on the distribution... >> You will notice that your cell phone does not run Linux. Totally false. I have played Doom on a cellphone with 64bit graphics running on Linux OS. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From paul at linuxaudiosystems.com Thu Jul 27 11:20:30 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jul 27 11:21:29 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8C4DB.1090800@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> Message-ID: <1154013631.5398.294.camel@localhost.localdomain> Someone called illiac wrote: > > Linux as it is ordinarily distributed is not a small-footprint real- > > time operating system. You will notice that your cell phone does not > > run Linux. There is a reason for that. i am sure nokia will be interested in your reason, since they don't seem to have heard of it yet. there are many cell phones that run linux. lets move on to the next basic error in your message: > > There is also a reason that the MPC4000 is a zero-latency device > > whereas a PC, even one running no digital audio device is zero-latency, least of all one with analog i/o's. > > Linux, is not a zero-latency device; it requires audio buffering and > > latency compensation and all that sh*t that drives people to work on latency compensation has absolutely nothing to do with what you are describing. audio buffering is caused by the design of the PCI bus, not linux. it also happens to reduce CPU load, which most people appreciate. > > If you haven't designed a real-time embedded application before -- > > e.g., the software that controls a piece of machinery or electronics > > -- then you are not in a good position to offer advice about how > > best to do this. if you have no experience with just real-time current linux kernels can be, then you are not in a good position to offer advice on how best to do this. > > There are public-domain RTOSes available that are suitable for this > > task. To those, you can add drivers for USB and FAT32. Without an > > RTOS to give you hard real-time scheduling, you have no chance to > > achieve the rock-steady timing that the MPC currently has. that sucks. that really does. because my linux systems have the same rock steady timing as the MPC. actually, their timing is even better than the MPC. somebody must have made a mistake around here. From jdboyd at jdboyd.net Thu Jul 27 12:55:24 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Thu Jul 27 13:10:22 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1153953674.2927.24.camel@mindpipe> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> Message-ID: <20060727165524.GC15526@jdboyd> On Wed, Jul 26, 2006 at 06:41:13PM -0400, Lee Revell wrote: > On Wed, 2006-07-26 at 17:29 -0500, Renich Bon ?iri? wrote: > > Thank you so much for the those words! ;=) > > > > As you saw at the links, the first goal is to get the source from > > Akai... even a beta. If that fails, we are gonna try and develop a whole OS. > > > > Why? That makes no sense. Why not just port Linux to it? One could take the point of view that linux is just the kernel, not the entire OS. Or one could, for the fun on if, port eCos. I worked on a project that used that on some audio cards. eCos supports that CPU already as well. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From leamsi.setroc at gmail.com Thu Jul 27 13:46:33 2006 From: leamsi.setroc at gmail.com (Ismael Cortes) Date: Thu Jul 27 13:46:41 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8C4DB.1090800@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> Message-ID: <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> On 7/27/06, Renich Bon ?iri? wrote: > > James Courtier-Dutton wrote: > Renich Bon ?iri? wrote: > > Well, everybody's telling me that Akai's OS is something else. Realtime > stuff and 2 or 3 engines and DSPs to manage. Besides, we have to support > akai's native file formats, like PROGRAM, MULTI and Sequence. > > I really don't know why... I'm just hearing what everybody says. You think > it shouldn't be that hard to port Linux and develop the effects and stuff, > and to support Akai's native format? Would you give me some arguments and > reasons? > > Thanks for the input! > The datasheet you posted it nice a detailed. We would need documentation > regarding the file formats, so we could implement support for them. > I think the biggest problem you will come up against will be getting the > equipment and the open source developers together. > Unless you donate the kit to each developer, nothing will happen. The kit > is far too expensive for a developer to purchase out of good will. > > James > > > Is the kit totally necesary? Can we build an emulator out of the service > manual? An emulator would be a natural step, i think. In any case, I have > some questions about a post a friend of mine made to the forum where it all > started. You can check it for yourself at: > http://www.mpc-forums.com/viewtopic.php?t=54825&start=60 > but I will paste it here. Can anybody comment on it? > > > Guys, > > Linux as it is ordinarily distributed is not a small-footprint real-time > operating system. You will notice that your cell phone does not run Linux. > There is a reason for that. There is also a reason that the MPC4000 is a > zero-latency device whereas a PC, even one running Linux, is not a > zero-latency device; it requires audio buffering and latency compensation > and all that sh*t that drives people to work on an MPC in the first place. > > If you haven't designed a real-time embedded application before -- e.g., > the software that controls a piece of machinery or electronics -- then you > are not in a good position to offer advice about how best to do this. > > There are public-domain RTOSes available that are suitable for this task. > To those, you can add drivers for USB and FAT32. Without an RTOS to give you > hard real-time scheduling, you have no chance to achieve the rock-steady > timing that the MPC currently has. > > -illiac > > You've just made a huge mistake... you just told linux zealots that linux is uncapable of something... now we are going to make it possible... ;) Anyway, you should read some stuff about linux and realtime. I agree totally that linux is not a hard-realtime OS, and was never designed to be such. So I wouldn't deploy it in a few places where QNX is king, but it's still quite capable. Here are a couple of links, it's your project, so it's totally your call: * http://linuxdevices.com/articles/AT8211887833.html this is an extract of a lkml message (available here http://lkml.org/lkml/2005/6/7/256) which compares different ways of achieving realtime in linux. * http://www.realtimelinuxfoundation.org/ it's basically a bunch of guys talking about how to make linux realtime, all the time. Check the "Variants" and "Solutions" sections. There seem to be a few hard-realtime solutions (unlike Molnar's patch, which gives you soft-realtime), but they seem quite hard to implement... haven't tried them, tho'. Now, I'm going back to lurking mode... Have fun! Regards. -Ismael C. From renich at woralelandia.com Thu Jul 27 13:54:26 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 13:54:44 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> Message-ID: <44C8FDD2.2040308@woralelandia.com> Ismael Cortes wrote: > On 7/27/06, Renich Bon ?iri? wrote: >> >> James Courtier-Dutton wrote: >> Renich Bon ?iri? wrote: >> >> Well, everybody's telling me that Akai's OS is something else. Realtime >> stuff and 2 or 3 engines and DSPs to manage. Besides, we have to support >> akai's native file formats, like PROGRAM, MULTI and Sequence. >> >> I really don't know why... I'm just hearing what everybody says. You >> think >> it shouldn't be that hard to port Linux and develop the effects and >> stuff, >> and to support Akai's native format? Would you give me some arguments >> and >> reasons? >> >> Thanks for the input! >> The datasheet you posted it nice a detailed. We would need >> documentation >> regarding the file formats, so we could implement support for them. >> I think the biggest problem you will come up against will be getting >> the >> equipment and the open source developers together. >> Unless you donate the kit to each developer, nothing will happen. >> The kit >> is far too expensive for a developer to purchase out of good will. >> >> James >> >> >> Is the kit totally necesary? Can we build an emulator out of the >> service >> manual? An emulator would be a natural step, i think. In any case, I >> have >> some questions about a post a friend of mine made to the forum where >> it all >> started. You can check it for yourself at: >> http://www.mpc-forums.com/viewtopic.php?t=54825&start=60 >> but I will paste it here. Can anybody comment on it? >> >> >> Guys, >> >> Linux as it is ordinarily distributed is not a small-footprint >> real-time >> operating system. You will notice that your cell phone does not run >> Linux. >> There is a reason for that. There is also a reason that the MPC4000 is a >> zero-latency device whereas a PC, even one running Linux, is not a >> zero-latency device; it requires audio buffering and latency >> compensation >> and all that sh*t that drives people to work on an MPC in the first >> place. >> >> If you haven't designed a real-time embedded application before -- >> e.g., >> the software that controls a piece of machinery or electronics -- >> then you >> are not in a good position to offer advice about how best to do this. >> >> There are public-domain RTOSes available that are suitable for this >> task. >> To those, you can add drivers for USB and FAT32. Without an RTOS to >> give you >> hard real-time scheduling, you have no chance to achieve the rock-steady >> timing that the MPC currently has. >> >> -illiac >> >> > > You've just made a huge mistake... you just told linux zealots that > linux is uncapable of something... now we are going to make it > possible... ;) > > Anyway, you should read some stuff about linux and realtime. I agree > totally that linux is not a hard-realtime OS, and was never designed > to be such. So I wouldn't deploy it in a few places where QNX is king, > but it's still quite capable. > > Here are a couple of links, it's your project, so it's totally your call: > > * http://linuxdevices.com/articles/AT8211887833.html this is an > extract of a lkml message (available here > http://lkml.org/lkml/2005/6/7/256) which compares different ways of > achieving realtime in linux. > > * http://www.realtimelinuxfoundation.org/ it's basically a bunch of > guys talking about how to make linux realtime, all the time. Check the > "Variants" and "Solutions" sections. There seem to be a few > hard-realtime solutions (unlike Molnar's patch, which gives you > soft-realtime), but they seem quite hard to implement... haven't tried > them, tho'. > > Now, I'm going back to lurking mode... > > Have fun! > > Regards. > -Ismael C. LOL. Thanks for the links! I will read some on the topic. -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060727/c268c908/renich.vcf From _ at whats-your.name Thu Jul 27 14:02:07 2006 From: _ at whats-your.name (carmen) Date: Thu Jul 27 14:02:09 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> Message-ID: <20060727180207.GB30303@replic.net> > You've just made a huge mistake... you just told linux zealots that > linux is uncapable of something... now we are going to make it > possible... ;) not that its incapable. im just wondering...why? you just coughed up $2995 for some buttons and embedded audio hw. wouldnt you rather use the OS you paid them to make run well on the device? does that OS not do what you want? why'd you buy the device then instead of a 99 euro drum pad set, a 999 euro laptop, and build you own software? at least that way you don't need to build an OS. or even sound or FS or file-format drivers from scratch.. not that im discouraging the project. i just think most people here would be a lot more interested in developing open hardware, then adding value to an already overpriced toy.. From renich at woralelandia.com Thu Jul 27 14:13:21 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 14:14:13 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <20060727180207.GB30303@replic.net> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> <20060727180207.GB30303@replic.net> Message-ID: <44C90241.5060604@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060727/ff3bf2b9/renich.vcf From radarsat1 at gmail.com Thu Jul 27 14:25:50 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jul 27 14:26:02 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <42107c280607271046led43764se8bd49df30cdd454@mail.gmail.com> Message-ID: <9b3e2dc20607271125w5d6befcckd6fa6fe2e41e3b35@mail.gmail.com> > "Variants" and "Solutions" sections. There seem to be a few > hard-realtime solutions (unlike Molnar's patch, which gives you > soft-realtime), but they seem quite hard to implement... haven't tried > them, tho'. I have done some development with RTLinux, a hard-realtime Linux solution, and it is a bit of a pain-in-the-ass to program for, since you are working in kernel-space and anything wrong you do will crash the whole computer. however, there is a way of using gdb with it, to catch errors before they cause a system crash. this makes things a little easier. and the fact is you can get VERY low latency using it. However, the project for which I was using it migrated our drivers to Linux 2.6, and when we did so, we found that we were able to get very very good timing out of it. This is because 2.6 incorporated the "preemptive" kernel locks, and when compiled with an HZ value of 1000 (that is, the basic OS interval timer for task switching), we were able to write code in user mode which had latency of less than 1ms. (This is including some I/O with a PCI board -- a data acquisition card to be precise.) So I would recommend not worrying too much about using a hard realtime system -- these days "soft" realtime seems to be rather good for most purposes. (The difference is that in soft realtime, you have no *guarantee* of the timing. Something could happen in an unrelated part of the OS that causes your process to wait longer than usual, and you could miss something. However, in practise I've found that running under a properly configured 2.6 kernel, this is rare enough that it's not really worth worrying about!) In this particular case, something to watch out for is whether there is an MMU. I think likely there is not. (Haven't check the linked docs) You'll probably have to run Linux sans-MMU, meaning that processes can step on each other if you're not careful! However, it's not *that* big a problem. Just makes development slightly more annoying. I don't have any information on latency reports for MMU-less Linux. Steve From jayv at synth.net Thu Jul 27 14:44:56 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jul 27 14:48:53 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C8C761.1070900@boosthardware.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <44C8C761.1070900@boosthardware.com> Message-ID: At 21:02 +0700 27/7/06, Patrick Shirkey wrote: >Renich Bon C'iric' wrote: >>>Linux as it is ordinarily distributed is not a small-footprint >>>real-time operating system. of course linux can be packaged as a small-footprint real-time operating system. it has been that way from the very beginning. distro's came second to the own-rolled. never forget that! distro's are not supposed to be embedded, or they wouldn't be distro's: they'd be "some device X, being used". the hardware wrapping embedded linux (or any similar kernel) *is* the distro. -- ; Jay Vaughan From jayv at synth.net Thu Jul 27 14:46:27 2006 From: jayv at synth.net (Jay Vaughan) Date: Thu Jul 27 14:49:02 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1154013631.5398.294.camel@localhost.localdomain> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <1154013631.5398.294.camel@localhost.localdomain> Message-ID: > > > There are public-domain RTOSes available that are suitable for this > > > task. To those, you can add drivers for USB and FAT32. Without an > > > RTOS to give you hard real-time scheduling, you have no chance to > > > achieve the rock-steady timing that the MPC currently has. >that sucks. that really does. because my linux systems have the same >rock steady timing as the MPC. actually, their timing is even better >than the MPC. somebody must have made a mistake around here. i assure you, linux performs on par with "other public-domain RTOSes" in the real-time department, in the right hands .. like all good instruments .. -- ; Jay Vaughan From renich at woralelandia.com Thu Jul 27 15:02:07 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 15:02:12 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <1154013631.5398.294.camel@localhost.localdomain> Message-ID: <44C90DAF.1070906@woralelandia.com> Jay Vaughan wrote: >> > > There are public-domain RTOSes available that are suitable for this >> > > task. To those, you can add drivers for USB and FAT32. Without an >> > > RTOS to give you hard real-time scheduling, you have no chance to >> > > achieve the rock-steady timing that the MPC currently has. >> that sucks. that really does. because my linux systems have the same >> rock steady timing as the MPC. actually, their timing is even better >> than the MPC. somebody must have made a mistake around here. > > i assure you, linux performs on par with "other public-domain RTOSes" > in the real-time department, in the right hands .. like all good > instruments .. > Guys, one question that, I believe, has been answered before. Is the service manual enough to start the OS from scratch? # Service Manual http://www.woralelandia.com/openmpc/service_manual # Where it all started http://www.mpc-forums.com/viewtopic.php?t=54825 Thanks for all the help and comments! I am very glad to have joined this mailing list ;=) -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060727/034b23be/renich.vcf From fons.adriaensen at skynet.be Thu Jul 27 15:16:26 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Thu Jul 27 15:15:41 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <1154013631.5398.294.camel@localhost.localdomain> Message-ID: <20060727191626.GC5920@linux-1.site> On Thu, Jul 27, 2006 at 08:46:27PM +0200, Jay Vaughan wrote: > > > > There are public-domain RTOSes available that are suitable for this > > > > task. To those, you can add drivers for USB and FAT32. Without an > > > > RTOS to give you hard real-time scheduling, you have no chance to > > > > achieve the rock-steady timing that the MPC currently has. > >that sucks. that really does. because my linux systems have the same > >rock steady timing as the MPC. actually, their timing is even better > >than the MPC. somebody must have made a mistake around here. > > i assure you, linux performs on par with "other public-domain RTOSes" > in the real-time department, in the right hands .. like all good > instruments .. Let me add one more voice. At my (current) work we develop space telecom equipment, all of it these days consisting of one or more dedicated interface cards plugged into a Linux PC. All processing is done in software. Sample frequencies are up to a few MHz, and latency requirements more demanding than for any audio work. Five years ago we used RTAI for the critical work. It was a lot of pain. Since then everything runs on standard Linux kernels optimised a bit for real-time. These days that means it's just a stock 2.6 kernel compiled with the right configuration. -- FA Lascia la spina, cogli la rosa. From gene.heskett at verizon.net Thu Jul 27 16:51:33 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu Jul 27 16:52:00 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C90DAF.1070906@woralelandia.com> References: <44C90DAF.1070906@woralelandia.com> Message-ID: <200607271651.34122.gene.heskett@verizon.net> On Thursday 27 July 2006 15:02, Renich Bon ?iri? wrote: >Jay Vaughan wrote: >>> > > There are public-domain RTOSes available that are suitable for >>> > > this task. To those, you can add drivers for USB and FAT32. >>> > > Without an RTOS to give you hard real-time scheduling, you have >>> > > no chance to achieve the rock-steady timing that the MPC >>> > > currently has. >>> >>> that sucks. that really does. because my linux systems have the same >>> rock steady timing as the MPC. actually, their timing is even better >>> than the MPC. somebody must have made a mistake around here. >> >> i assure you, linux performs on par with "other public-domain RTOSes" >> in the real-time department, in the right hands .. like all good >> instruments .. > >Guys, one question that, I believe, has been answered before. Is the >service manual enough to start the OS from scratch? Finally, a question is raised that I can make a comment on, based on 55 years of chasing electrons around for a living. Yeah, I'm getting to be a chrotchety old coot in my retirement years. :) ># Service Manual >http://www.woralelandia.com/openmpc/service_manual After spending about half an hour perusing that pdf, I can, as a C.E.T. who has carved some code in a past life, say that the answer is a rather resounding no. There is nowhere near enough there, without chaseing each and every chip maker down and somehow acquiring all the interface requirements. Properly specified, like we used to be able to get chip info back in the 80's, I'd imagine that pdf would have to grow another thousand pages. ># Where it all started >http://www.mpc-forums.com/viewtopic.php?t=54825 > >Thanks for all the help and comments! I am very glad to have joined this >mailing list ;=) I can't help but echo the reticence already expressed here regarding the proprietary nature of this device. If Akai wants to make money on the hardware by selling it to die-hard linux professional audio people, either they do their own OS for it and charge whatever they think the whole package is worth, or open the device up just as if it was a GPL piece of software and be prepared to sell the hardware for a decent price after assuming a sales level of x many units. I certainly don't see 3 grand worth of parts, pcb, drive and silk screening there, far less in fact. I suspect that there will be very little support offered by the average liux coder if he knows the patches he writes will disappear into something that is not going to be open-sourced. From my viewpoint, Akai's legal dept., who is obviously controlling what Renich can say, will see to it that the product fails. Its up to Akai to make a liar out of me. If they would join the open source camp by supporting the coders with all the info, publicly available to any and all, that they will need to write the drivers this device will need, distribute this OS under the GPL with a server that lets *anyone* download it for free, or on a mailable cd for a couple of bucks american, while selling the hardware for $1000 to $1500, and watch the hardware sales blossum like our wild flowers along the interstate. Thats because the unshackled coders will write stuff that stretches the limits of what the hardware can do, just to see if they can. Its rather like climbing Mt. Everest, because its there. :) -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jdboyd at jdboyd.net Thu Jul 27 18:30:31 2006 From: jdboyd at jdboyd.net (Joshua Boyd) Date: Thu Jul 27 18:45:30 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C90DAF.1070906@woralelandia.com> References: <44C7BC64.20204@woralelandia.com> <3c808a150607261526x685bc10bg537c7e6c092b0b23@mail.gmail.com> <44C7ECD9.6060500@woralelandia.com> <1153953674.2927.24.camel@mindpipe> <44C7F206.4030100@woralelandia.com> <44C8911A.3000604@superbug.co.uk> <44C8C4DB.1090800@woralelandia.com> <1154013631.5398.294.camel@localhost.localdomain> <44C90DAF.1070906@woralelandia.com> Message-ID: <20060727223031.GA16611@jdboyd> On Thu, Jul 27, 2006 at 02:02:07PM -0500, Renich Bon ??iri?? wrote: > Jay Vaughan wrote: > >> > > There are public-domain RTOSes available that are suitable for this > >> > > task. To those, you can add drivers for USB and FAT32. Without an > >> > > RTOS to give you hard real-time scheduling, you have no chance to > >> > > achieve the rock-steady timing that the MPC currently has. > >>that sucks. that really does. because my linux systems have the same > >>rock steady timing as the MPC. actually, their timing is even better > >>than the MPC. somebody must have made a mistake around here. > > > >i assure you, linux performs on par with "other public-domain RTOSes" > >in the real-time department, in the right hands .. like all good > >instruments .. > > > Guys, one question that, I believe, has been answered before. Is the > service manual enough to start the OS from scratch? > > # Service Manual > http://www.woralelandia.com/openmpc/service_manual No. You also need the CPU manual and the SCSI manuals, plus probably some other manuals that I'm not bothering to list. On the up side, those manuals are lilikely easy to find. But why start from scratch. If you don't like linux, fine, but at least build on some existing OS. Heck, even Akai is likely buying a third party RTOS to build their system on top of. -- Joshua D. Boyd jdboyd@jdboyd.net http://www.jdboyd.net/ http://www.joshuaboyd.org/ From renich at woralelandia.com Thu Jul 27 19:34:42 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Thu Jul 27 19:34:52 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <200607271651.34122.gene.heskett@verizon.net> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> Message-ID: <44C94D92.1000308@woralelandia.com> Gene Heskett wrote: > On Thursday 27 July 2006 15:02, Renich Bon ?iri? wrote: > >> Jay Vaughan wrote: >> >>>> > > There are public-domain RTOSes available that are suitable for >>>> > > this task. To those, you can add drivers for USB and FAT32. >>>> > > Without an RTOS to give you hard real-time scheduling, you have >>>> > > no chance to achieve the rock-steady timing that the MPC >>>> > > currently has. >>>> >>>> that sucks. that really does. because my linux systems have the same >>>> rock steady timing as the MPC. actually, their timing is even better >>>> than the MPC. somebody must have made a mistake around here. >>>> >>> i assure you, linux performs on par with "other public-domain RTOSes" >>> in the real-time department, in the right hands .. like all good >>> instruments .. >>> >> Guys, one question that, I believe, has been answered before. Is the >> service manual enough to start the OS from scratch? >> > > Finally, a question is raised that I can make a comment on, based on 55 > years of chasing electrons around for a living. Yeah, I'm getting to be a > chrotchety old coot in my retirement years. :) > > >> # Service Manual >> http://www.woralelandia.com/openmpc/service_manual >> > > After spending about half an hour perusing that pdf, I can, as a C.E.T. who > has carved some code in a past life, say that the answer is a rather > resounding no. There is nowhere near enough there, without chaseing each > and every chip maker down and somehow acquiring all the interface > requirements. Properly specified, like we used to be able to get chip > info back in the 80's, I'd imagine that pdf would have to grow another > thousand pages. > > >> # Where it all started >> http://www.mpc-forums.com/viewtopic.php?t=54825 >> >> Thanks for all the help and comments! I am very glad to have joined this >> mailing list ;=) >> > > I can't help but echo the reticence already expressed here regarding the > proprietary nature of this device. If Akai wants to make money on the > hardware by selling it to die-hard linux professional audio people, either > they do their own OS for it and charge whatever they think the whole > package is worth, or open the device up just as if it was a GPL piece of > software and be prepared to sell the hardware for a decent price after > assuming a sales level of x many units. I certainly don't see 3 grand > worth of parts, pcb, drive and silk screening there, far less in fact. > > I suspect that there will be very little support offered by the average > liux coder if he knows the patches he writes will disappear into something > that is not going to be open-sourced. > > From my viewpoint, Akai's legal dept., who is obviously controlling what > Renich can say, will see to it that the product fails. Its up to Akai to > make a liar out of me. If they would join the open source camp by > supporting the coders with all the info, publicly available to any and > all, that they will need to write the drivers this device will need, > distribute this OS under the GPL with a server that lets *anyone* download > it for free, or on a mailable cd for a couple of bucks american, while > selling the hardware for $1000 to $1500, and watch the hardware sales > blossum like our wild flowers along the interstate. Thats because the > unshackled coders will write stuff that stretches the limits of what the > hardware can do, just to see if they can. Its rather like climbing Mt. > Everest, because its there. :) > Well, I think we are getting a bit... carried away. I am not from akai, in fact, my purpose is to ask akai to help us help them because there OS sucks. It has too many bugs... that's the purpose of all this. If they refuse, then I am willing to start an OS myself. That's all. -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 289 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060727/07ec2e5f/renich-0001.vcf From loki.davison at gmail.com Thu Jul 27 21:27:56 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jul 27 21:28:04 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C94D92.1000308@woralelandia.com> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> Message-ID: On 7/28/06, Renich Bon ?iri? wrote: > > > Gene Heskett wrote: > > On Thursday 27 July 2006 15:02, Renich Bon ?iri? wrote: > > > >> Jay Vaughan wrote: > >> > >>>> > > There are public-domain RTOSes available that are suitable for > >>>> > > this task. To those, you can add drivers for USB and FAT32. > >>>> > > Without an RTOS to give you hard real-time scheduling, you have > >>>> > > no chance to achieve the rock-steady timing that the MPC > >>>> > > currently has. > >>>> > >>>> that sucks. that really does. because my linux systems have the same > >>>> rock steady timing as the MPC. actually, their timing is even better > >>>> than the MPC. somebody must have made a mistake around here. > >>>> > >>> i assure you, linux performs on par with "other public-domain RTOSes" > >>> in the real-time department, in the right hands .. like all good > >>> instruments .. > >>> > >> Guys, one question that, I believe, has been answered before. Is the > >> service manual enough to start the OS from scratch? > >> > > > > Finally, a question is raised that I can make a comment on, based on 55 > > years of chasing electrons around for a living. Yeah, I'm getting to be a > > chrotchety old coot in my retirement years. :) > > > > > >> # Service Manual > >> http://www.woralelandia.com/openmpc/service_manual > >> > > > > After spending about half an hour perusing that pdf, I can, as a C.E.T. > who > > has carved some code in a past life, say that the answer is a rather > > resounding no. There is nowhere near enough there, without chaseing each > > and every chip maker down and somehow acquiring all the interface > > requirements. Properly specified, like we used to be able to get chip > > info back in the 80's, I'd imagine that pdf would have to grow another > > thousand pages. > > > > > >> # Where it all started > >> http://www.mpc-forums.com/viewtopic.php?t=54825 > >> > >> Thanks for all the help and comments! I am very glad to have joined this > >> mailing list ;=) > >> > > > > I can't help but echo the reticence already expressed here regarding the > > proprietary nature of this device. If Akai wants to make money on the > > hardware by selling it to die-hard linux professional audio people, either > > they do their own OS for it and charge whatever they think the whole > > package is worth, or open the device up just as if it was a GPL piece of > > software and be prepared to sell the hardware for a decent price after > > assuming a sales level of x many units. I certainly don't see 3 grand > > worth of parts, pcb, drive and silk screening there, far less in fact. > > > > I suspect that there will be very little support offered by the average > > liux coder if he knows the patches he writes will disappear into something > > that is not going to be open-sourced. > > > > From my viewpoint, Akai's legal dept., who is obviously controlling what > > Renich can say, will see to it that the product fails. Its up to Akai to > > make a liar out of me. If they would join the open source camp by > > supporting the coders with all the info, publicly available to any and > > all, that they will need to write the drivers this device will need, > > distribute this OS under the GPL with a server that lets *anyone* download > > it for free, or on a mailable cd for a couple of bucks american, while > > selling the hardware for $1000 to $1500, and watch the hardware sales > > blossum like our wild flowers along the interstate. Thats because the > > unshackled coders will write stuff that stretches the limits of what the > > hardware can do, just to see if they can. Its rather like climbing Mt. > > Everest, because its there. :) > > > > Well, I think we are getting a bit... carried away. I am not from akai, > in fact, my purpose is to ask akai to help us help them because there OS > sucks. It has too many bugs... that's the purpose of all this. If they > refuse, then I am willing to start an OS myself. That's all. > > you mean you are willing to try and find some one to write you a new OS for free? How much of the coding will you do? How about you just buy a little rack mount pc and an mpd16? then you have the pads from the mpc and a whole lot more processing power. You could put a nice interface in the same little rack box and then you'll have less random stuff to carry to a gig and might actually build a better intergrated solution that everyone can use. You might get a lot more support from everyone then. Ebay might be a good place for your mpc. Loki From gene.heskett at verizon.net Thu Jul 27 21:38:01 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Thu Jul 27 21:38:31 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44C94D92.1000308@woralelandia.com> References: <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> Message-ID: <200607272138.01484.gene.heskett@verizon.net> On Thursday 27 July 2006 19:34, Renich Bon ?iri? wrote: [...] >> >> From my viewpoint, Akai's legal dept., who is obviously controlling >> what Renich can say, will see to it that the product fails. Its up to >> Akai to make a liar out of me. If they would join the open source camp >> by supporting the coders with all the info, publicly available to any >> and all, that they will need to write the drivers this device will >> need, distribute this OS under the GPL with a server that lets *anyone* >> download it for free, or on a mailable cd for a couple of bucks >> american, while selling the hardware for $1000 to $1500, and watch the >> hardware sales blossum like our wild flowers along the interstate. >> Thats because the unshackled coders will write stuff that stretches the >> limits of what the hardware can do, just to see if they can. Its >> rather like climbing Mt. Everest, because its there. :) > >Well, I think we are getting a bit... carried away. I am not from akai, >in fact, my purpose is to ask akai to help us help them because there OS >sucks. It has too many bugs... that's the purpose of all this. If they >refuse, then I am willing to start an OS myself. That's all. First one has to open an effective channel of communications in order to get close enough to somebody who would know what an NDA is, something I've tried several times over the decades with only one success, usually you find somebody co-operative who makes you think you might have a chance at getting some assistance, but 3 days later you call back to confirm a detail and that person has been fired or transferred out of that dept., primarily one suspects for the simple act of getting too close to the customer. However, Renish, if you are not representing Akai in this, then why the secrecy? Akai is going to want to know why you want to know all this stuff, and just to play cma, I wouldn't even try to put a coat of varnish on it. Tell them straight up that the hardware is great but the OS sucks and you want to fix it, writing it from scratch in a clean room scenario, meaning you will never see a copy of their src, just the specs that writing to such and such an address writes to what register, and what every bit or byte written makes it do what. AIUI, then you can GPL it, or if no GPL'd libraries or anything like that is used, you could make it proprietary. But we both know you'll get a lot more help if its open and GPL'd. And, just to get some stability, for every register you write to using their specs for whats written vs whats supposed to happen, I'd take the time to verify that the results you get and their specs agree. I've found more than one bug, a couple of them fairly serious, in the hardware using that exersize it all technique. I expect you will do whatever and however you want in any event, so I'll go away and see if my rocking chair still rocks, or something. :) -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From loki.davison at gmail.com Fri Jul 28 02:03:20 2006 From: loki.davison at gmail.com (Loki Davison) Date: Fri Jul 28 02:03:34 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <200607272138.01484.gene.heskett@verizon.net> References: <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <200607272138.01484.gene.heskett@verizon.net> Message-ID: On 7/28/06, Gene Heskett wrote: > On Thursday 27 July 2006 19:34, Renich Bon ?iri? wrote: > [...] > >> > >> From my viewpoint, Akai's legal dept., who is obviously controlling > >> what Renich can say, will see to it that the product fails. Its up to > >> Akai to make a liar out of me. If they would join the open source camp > >> by supporting the coders with all the info, publicly available to any > >> and all, that they will need to write the drivers this device will > >> need, distribute this OS under the GPL with a server that lets *anyone* > >> download it for free, or on a mailable cd for a couple of bucks > >> american, while selling the hardware for $1000 to $1500, and watch the > >> hardware sales blossum like our wild flowers along the interstate. > >> Thats because the unshackled coders will write stuff that stretches the > >> limits of what the hardware can do, just to see if they can. Its > >> rather like climbing Mt. Everest, because its there. :) > > > >Well, I think we are getting a bit... carried away. I am not from akai, > >in fact, my purpose is to ask akai to help us help them because there OS > >sucks. It has too many bugs... that's the purpose of all this. If they > >refuse, then I am willing to start an OS myself. That's all. > > First one has to open an effective channel of communications in order to > get close enough to somebody who would know what an NDA is, something I've > tried several times over the decades with only one success, usually you > find somebody co-operative who makes you think you might have a chance at > getting some assistance, but 3 days later you call back to confirm a > detail and that person has been fired or transferred out of that dept., > primarily one suspects for the simple act of getting too close to the > customer. > > However, Renish, if you are not representing Akai in this, then why the > secrecy? > > Akai is going to want to know why you want to know all this stuff, and just > to play cma, I wouldn't even try to put a coat of varnish on it. Tell > them straight up that the hardware is great but the OS sucks and you want > to fix it, writing it from scratch in a clean room scenario, meaning you > will never see a copy of their src, just the specs that writing to such > and such an address writes to what register, and what every bit or byte > written makes it do what. AIUI, then you can GPL it, or if no GPL'd > libraries or anything like that is used, you could make it proprietary. > But we both know you'll get a lot more help if its open and GPL'd. > > And, just to get some stability, for every register you write to using > their specs for whats written vs whats supposed to happen, I'd take the > time to verify that the results you get and their specs agree. I've found > more than one bug, a couple of them fairly serious, in the hardware using > that exersize it all technique. > > I expect you will do whatever and however you want in any event, so I'll go > away and see if my rocking chair still rocks, or something. :) > rock on! ..... sorry i just had to! ;) Loki From gene.heskett at verizon.net Fri Jul 28 04:05:01 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri Jul 28 04:05:18 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation =?utf-8?q?Open=09Source?= Project In-Reply-To: References: <200607272138.01484.gene.heskett@verizon.net> Message-ID: <200607280405.02083.gene.heskett@verizon.net> On Friday 28 July 2006 02:03, Loki Davison wrote: >On 7/28/06, Gene Heskett wrote: >> On Thursday 27 July 2006 19:34, Renich Bon ?iri? wrote: >> [...] >> [...] >> >> I expect you will do whatever and however you want in any event, so >> I'll go away and see if my rocking chair still rocks, or something. :) > >rock on! > >..... sorry i just had to! ;) > >Loki Well, in fact I mowed the front yard, weeded my little garden, changed the beetle bags, stood on the front deck taking a pix about every 2 minutes while some sort of a lilly the missus has in a big pot sitting on the deck railing, a lilly she has had since long before me, opened up 4 blooms yesterday morning. And I finally got through to the cvs server and updated my milling machines emc2 driver program, but now it won't run, something needs updated in the stepper_inch.ini file according to the error message as it dies. Fur a retired old coot, I was busy and never did find the rocker, I think its in the front room someplace. :-) Rockers are for old farts, and while I'm 71, my mind hasn't quite gotten to the sit down and die stage. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From kjetil at ccrma.stanford.edu Fri Jul 28 03:25:26 2006 From: kjetil at ccrma.stanford.edu (kjetil@ccrma.stanford.edu) Date: Fri Jul 28 04:44:28 2006 Subject: [linux-audio-dev] [ANN] das_watchdog V0.2.4 and jack_capture V0.3.7 Message-ID: New source location: http://www.notam02.no/~kjetism/src/ (Sorry, I have temporarily lost access to both my previously used upload directories) das_watchdog ************************************************************************* Whenever a program locks up the machine, das_watchdog will temporarily sets all realtime process to non-realtime for 8 seconds. You will get an xmessage window up on the screen whenever that happens. Changes 0.2.3->0.2.4 -------------------- *Test if the xmessage program found during the make process is a valid executable. If not, search the $PATH instead. This should fix it for Gentoo when the pro-audio overlay is updated to at least this version. *Various modifications for the High Res Timer, which should be used instead of setting the timer interrupt process to SCHED_FIFO/99. jack_capture ************************************************************************* jack_capture is a small program to capture whatever sound is going out to your speakers into a file without having to patch jack connections, fiddle around with fileformats, or set options on the argument line. This is the program I always wanted to have for jack, but no one made. So here it is. Changes 0.3.1 -> 0.3.7: ----------------------- *Fixed potentional buffer underrun error. *Fixed potentional ringbuffer size allocation miscalculation. *Better way to set leading zeros in filename. Thanks to Melanie. *Better underrun handling. Thanks to Dmitry Baikov. *Added support for jack buffer size change. *Removed some unnecessary code and comments *Beautified code a bit. *Fixed a bug in the reconnection code. *Beautified code a lot. *Changed bufsize argument to accept seconds instead of frames. Default buffer size is 60 seconds. *Improved documentation and help option. *Beautified source a bit. *Fixed bug in ringbuffer size allocation. *Fixed so that more than one instance of jack_capture can run at once. From renich at woralelandia.com Fri Jul 28 14:24:05 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Fri Jul 28 14:24:19 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <200607272138.01484.gene.heskett@verizon.net> References: <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <200607272138.01484.gene.heskett@verizon.net> Message-ID: <44CA5645.3030701@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060728/03e99aed/renich.vcf From renich at woralelandia.com Fri Jul 28 14:29:42 2006 From: renich at woralelandia.com (=?ISO-8859-2?Q?Renich_Bon_=C6iri=E6?=) Date: Fri Jul 28 14:29:58 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> Message-ID: <44CA5796.1050706@woralelandia.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 378 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060728/3f664882/renich.vcf From gene.heskett at verizon.net Fri Jul 28 15:07:12 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri Jul 28 15:08:00 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44CA5645.3030701@woralelandia.com> References: <200607272138.01484.gene.heskett@verizon.net> <44CA5645.3030701@woralelandia.com> Message-ID: <200607281507.12105.gene.heskett@verizon.net> On Friday 28 July 2006 14:24, Renich Bon ?iri? wrote: >Gene Heskett wrote: [...] >Did I say that this was a secret project? I have sent the urls to the >official Open Source initiative site and the forum where it all started. >I will sent them again. > ># Forum >http://www.mpc-forums.com/viewtopic.php?t=54825 ># Site >http://www.woralelandia.com/openmpc/ Thanks. > >And of course it would be GPL, at least from our side and if Akai agrees >to help, they would have to decide what kind of licence, still, I would >fight for the GPL at all time. Its YOUR project, YOU should set the license, and Akai can help, or not help. >Actually, I'm not a programmer or have any direct contact with Akai. I'm >only trying to organize things. And I need collaborators! Getting collaborators is going to be 10,000% easier if its GPL from the gitgo. And I still haven't found that rocker to sit in. Amanda and emc2 are taking too much of my time. I build the daily snapshot of amanda and install it for the upcoming nights backup run, and screech like a canary if it upchucks, which it did last night. And emc2 seems to have lost its path through the parport & doesn't run the motors with the most recent build. And somewhere, I have to find the time to update 2 machines to FC5 or kubuntu-6.06 here, this one from a considerably hacked up FC2, and my firewall box from a heavily updated RH7.3, whose support officially ends Dec 31. I'll find that rocker someday & then you'll likely not have to put up with me anymore. Till, then, we'll just keep on trying to 'git-r-done'. :) -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From jens.andreasen at chello.se Fri Jul 28 17:27:52 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Jul 28 17:28:03 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44CA5796.1050706@woralelandia.com> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <44CA5796.1050706@woralelandia.com> Message-ID: <1154122072.9274.981.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2006-07-28 at 13:29 -0500, Renich Bon ?iri? wrote: - > > you mean you are willing to try and find some one to write you a > > new > > OS for free? How much of the coding will you do? How about you just > > buy a little rack mount pc and an mpd16? then you have the pads > > from > > the mpc and a whole lot more processing power. You could put a nice > > interface in the same little rack box and then you'll have less > > random > > stuff to carry to a gig and might actually build a better > > intergrated > > solution that everyone can use. You might get a lot more support > > from > > everyone then. Ebay might be a good place for your mpc. > > > > Loki > Well, that would be selfish. I have the other users in mind. What good > would it be for others if I do as you say? We already bought the > hardware and the OS isn't what it should be. Maybe they don't want to > support it, maybe they can't. I don't care, I do care about making > music and the users at the end. That is why I am trying. -- Renich! There is one thing you did not tell us. What is it that is so annoying? Is it crashing or is it doing the wrong thing or is it perhaps stopping to respond within reasonable time? Others have said that it is very likely that Akai have bought their RT-OS from a third-party vendor. So they are under an NDA and there is no legal way for them to show the source for that. OTOH, the thing works mostly like you want it to, yes? So it might be a small adjustment that is needed rather than a major rewrite, no? Like Gene says, you'll have to get thru to a senior engineer and file a proper bug-report. This should include a method for provoking the bug (as in: When I do like this, after having done that, it always ...) Most probably it is a thinko on behalf of Akai regarding the application on top of the RT-OS. Reasonably easily fixed by one guy at Akai. From renich at woralelandia.com Sat Jul 29 00:48:57 2006 From: renich at woralelandia.com (=?ISO-8859-2?Q?Renich_Bon_=C6iri=E6?=) Date: Sat Jul 29 00:49:12 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1154122072.9274.981.camel@c80-216-124-251.cm-upc.chello.se> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <44CA5796.1050706@woralelandia.com> <1154122072.9274.981.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <44CAE8B9.2010800@woralelandia.com> Jens M Andreasen wrote: > On Fri, 2006-07-28 at 13:29 -0500, Renich Bon ?iri? wrote: > > - > > >>> you mean you are willing to try and find some one to write you a >>> new >>> OS for free? How much of the coding will you do? How about you just >>> buy a little rack mount pc and an mpd16? then you have the pads >>> from >>> the mpc and a whole lot more processing power. You could put a nice >>> interface in the same little rack box and then you'll have less >>> random >>> stuff to carry to a gig and might actually build a better >>> intergrated >>> solution that everyone can use. You might get a lot more support >>> from >>> everyone then. Ebay might be a good place for your mpc. >>> >>> Loki >>> > > >> Well, that would be selfish. I have the other users in mind. What good >> would it be for others if I do as you say? We already bought the >> hardware and the OS isn't what it should be. Maybe they don't want to >> support it, maybe they can't. I don't care, I do care about making >> music and the users at the end. That is why I am trying. >> Well, the system has some major, important bugs. You could search a list of it on the unnofficial support forum, www.mpc-forums.com, since akai doesn't even have a bug tracking system, at least outside. The last version was released 1.5 years ago. The update has a great number of bugs still in it. This bugs could be corrected easily, the developers say, but they haven't been corrected. Support from akai is very strange, you do have a support@akaipro.com email, but they usually just say that akai has nothing to do with it and that you should forget it. The hardware is great... the service isn't... they could be so successful,.. -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 378 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060728/fdd1b49a/renich.vcf From mle+la at mega-nerd.com Sat Jul 29 07:31:02 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Jul 29 07:31:14 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile Message-ID: <20060729213102.7e67822c.mle+la@mega-nerd.com> Hi all, Thanks to suggestions from people here I now have a relatively complete C++ wrapper for libsndfile: http://www.mega-nerd.com/tmp/sndfile.hh There is also a pre-release of libsndfile which includes a test for this wrapper: http://www.mega-nerd.com/tmp/libsndfile-1.0.17pre7.tar.gz C++ users, please comment. Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Even among Europe's Muslim minorities, roughly one-in-seven in France, Spain, and Great Britain feel that suicide bombings against civilian targets can at least sometimes be justified to defend Islam against its enemies." -- http://pewglobal.org/reports/display.php?ReportID=253 From lars.luthman at gmail.com Sat Jul 29 07:53:19 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jul 29 07:53:29 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <20060729213102.7e67822c.mle+la@mega-nerd.com> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> Message-ID: <1154173999.26591.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sat, 2006-07-29 at 21:31 +1000, Erik de Castro Lopo wrote: > Hi all, > > Thanks to suggestions from people here I now have a relatively > complete C++ wrapper for libsndfile: > > http://www.mega-nerd.com/tmp/sndfile.hh > > There is also a pre-release of libsndfile which includes a > test for this wrapper: > > http://www.mega-nerd.com/tmp/libsndfile-1.0.17pre7.tar.gz > > C++ users, please comment. The 4 different overloaded versions of the read, readf, write, and writef functions will cause ambiguities that will force you to cast them to their respective types in order to use pointers to them, for example in functors (e.g. a sigc++ slot), like this: mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*, sf_count_t))&Sndfile::read); If they were specialisations of the same template functions instead, with the sample type as template parameter, you'd only have to write this: mem_fun(sndobj, &Sndfile::read); which is a lot nicer and easier to read. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060729/9b32f2f7/attachment.bin From mle+la at mega-nerd.com Sat Jul 29 09:14:44 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Jul 29 09:14:56 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <1154173999.26591.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> <1154173999.26591.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: <20060729231444.51d40f3c.mle+la@mega-nerd.com> Lars Luthman wrote: > The 4 different overloaded versions of the read, readf, write, and > writef functions will cause ambiguities that will force you to cast them > to their respective types in order to use pointers to them, for example > in functors (e.g. a sigc++ slot), like this: > > mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*, > sf_count_t))&Sndfile::read); > > If they were specialisations of the same template functions instead, > with the sample type as template parameter, you'd only have to write > this: > > mem_fun(sndobj, &Sndfile::read); > > which is a lot nicer and easier to read. Interesting use case. I'm not even close to being an expert in C++ templates, but I suppose that read function would then be defined as something like: template sf_count_t read (T *ptr, sf_count_t items) ; SO how do I ensure that only gets specialised as short, int, float and double? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ The difference between genius and stupidity is that genius has its limits. From lars.luthman at gmail.com Sat Jul 29 09:29:26 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jul 29 09:29:34 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <20060729231444.51d40f3c.mle+la@mega-nerd.com> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> <1154173999.26591.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <20060729231444.51d40f3c.mle+la@mega-nerd.com> Message-ID: <1154179766.10662.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> On Sat, 2006-07-29 at 23:14 +1000, Erik de Castro Lopo wrote: > Lars Luthman wrote: > > > The 4 different overloaded versions of the read, readf, write, and > > writef functions will cause ambiguities that will force you to cast them > > to their respective types in order to use pointers to them, for example > > in functors (e.g. a sigc++ slot), like this: > > > > mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*, > > sf_count_t))&Sndfile::read); > > > > If they were specialisations of the same template functions instead, > > with the sample type as template parameter, you'd only have to write > > this: > > > > mem_fun(sndobj, &Sndfile::read); > > > > which is a lot nicer and easier to read. > > Interesting use case. > > I'm not even close to being an expert in C++ templates, but > I suppose that read function would then be defined as something > like: > > template sf_count_t read (T *ptr, sf_count_t items) ; > > SO how do I ensure that only gets specialised as short, > int, float and double? class Sndfile { ... template sf_count_t read (T *ptr, sf_count_t items); ... }; template <> sf_count_t Sndfile::read(short* ptr, sf_count_t items) { ... } template <> sf_count_t Sndfile::read(int* ptr, sf_count_t items) { ... } template <> sf_count_t Sndfile::read(float* ptr, sf_count_t items) { ... } template <> sf_count_t Sndfile::read(double* ptr, sf_count_t items) { ... } ...and nothing more. If you don't have a generic implementation anyone who tries to instantiate the template with an unsupported type will get a compilation error. I don't think there is a way to actually prevent someone else from writing a generic implementation or a different specialisation in their own source, but if they try that they should _really_ know what they are doing. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060729/20949c8c/attachment.bin From jens.andreasen at chello.se Sat Jul 29 10:49:26 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Jul 29 10:49:35 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <44CAE8B9.2010800@woralelandia.com> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <44CA5796.1050706@woralelandia.com> <1154122072.9274.981.camel@c80-216-124-251.cm-upc.chello.se> <44CAE8B9.2010800@woralelandia.com> Message-ID: <1154184566.9274.1053.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2006-07-28 at 23:48 -0500, Renich Bon ?iri? wrote: > Well, the system has some major, important bugs. You could search a list > of it on the unnofficial support forum, www.mpc-forums.com, since akai > doesn't even have a bug tracking system, at least outside. > Ehh ... I looked around a little in: Exchange tips and tricks for the Akai MPC4000 26864 Posts, 3600 Threads Is that the one? There is no search function in the forum, and quite a low noise to content ratio. I can understand if akai is not willing to manually browse through it all ... I found one report of a "missing file", but nobody chiming in with a "me too", so there is no pattern there to follow. On the surface, that report could also look like a "dog ate my homework" :-) > The last version was released 1.5 years ago. The update has a great > number of bugs still in it. This bugs could be corrected easily, the > developers say, but they haven't been corrected. > What developers, akai? Open source advocates? And again, what bug? Saying "a great number" is hard to follow up on. In the forum I see many suggestions that could be compiled into some kind of wish-list. I would recommend that those people pick up some abondoned PC from the garbage bin, install Linux, and then join us here. The chance of akai open sourcing their application is next to nil. They would (and should) consider their knowhow to be trade-secrets, which means that everything would be under an NDA. Furthermore, it would also be riddled with licensed patents, so of very little use to us. That the OS (or application) is not being updated is not nescesarily a bad thing. It might be so that the real bugs have been ironed out and compliance with specifications have been achieved. For that matter, the OS for my hardware synthesizer haven't been updated since late '84 (or was that early '85?) The OS misinterpreted an "all-notes-off" to be a "system-reset", which was the end of fun with inter-operability. Despite that there are no further updates after that, I am still happy and I use it every day :-) > Support from akai is very strange, you do have a support@akaipro.com > email, but they usually just say that akai has nothing to do with it and > that you should forget it. > > The hardware is great... the service isn't... they could be so > successful,.. It's a $3K unit! If they have managed to ship, say 3000 units, they would be close to (or beyond) break-even. My guess is, from an accountants POV, that they are successful. High profiled synthesizers are like Lambourginis and Ferraris: Everybody knows what they look like and what they can do, but only the few select can afford to actually own one and use it. Talking of which: Porshe still haven't fixed the bug in the back-suspension of the 911 Carrera ... () -- From mle+la at mega-nerd.com Sat Jul 29 20:04:01 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Jul 29 20:04:14 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <20060729213102.7e67822c.mle+la@mega-nerd.com> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> Message-ID: <20060730100401.c6d133cd.mle+la@mega-nerd.com> Erik de Castro Lopo wrote: > Hi all, > > Thanks to suggestions from people here I now have a relatively > complete C++ wrapper for libsndfile: > > http://www.mega-nerd.com/tmp/sndfile.hh I've updated this with the following: - Templatize the read/write/readf/writef methods. - Stop (potentially) leaking SNDFILE* pointers in the open*() methods. - Change the SF_INFO pointer to const in: Sndfile (const char *path, int mode, const SF_INFO *sfinfo_in) ; Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry." -- Eric S. Raymond From mle+la at mega-nerd.com Sat Jul 29 23:43:15 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Jul 29 23:43:25 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <20060730100401.c6d133cd.mle+la@mega-nerd.com> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> <20060730100401.c6d133cd.mle+la@mega-nerd.com> Message-ID: <20060730134315.f7fa70c2.mle+la@mega-nerd.com> Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > Hi all, > > > > Thanks to suggestions from people here I now have a relatively > > complete C++ wrapper for libsndfile: > > > > http://www.mega-nerd.com/tmp/sndfile.hh An another update incorporating a number of suggestions from Daniel Schmitt. - The SF_INFO struct is now private. - Add frames, channels, format and samplerate getters. - Sndfile constructor and open method now require a mode (SFM_READ, SFM_RDWR or SFM_WRITE) and optional format/ channels/samplerate. The latest is at the same URL as the above. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "No Silicon Heaven? Preposterous! Where would all the calculators go?" -- Kryten, Red Dwarf From taybin at earthlink.net Sun Jul 30 15:47:03 2006 From: taybin at earthlink.net (Taybin Rutkin) Date: Sun Jul 30 15:46:42 2006 Subject: [linux-audio-dev] C++ wrapper for libsndfile In-Reply-To: <1154179766.10662.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> References: <20060729213102.7e67822c.mle+la@mega-nerd.com> <1154173999.26591.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> <20060729231444.51d40f3c.mle+la@mega-nerd.com> <1154179766.10662.8.camel@c-6274e055.456-1-64736c13.cust.bredbandsbolaget.se> Message-ID: On Jul 29, 2006, at 9:29 AM, Lars Luthman wrote: > I don't think there is a way to actually prevent someone else from > writing a generic implementation or a different specialisation in > their > own source, but if they try that they should _really_ know what > they are > doing. I've heard that a mechanism for disallowing certain types in templates will be in the next version of C++. Taybin From renich at woralelandia.com Mon Jul 31 01:25:00 2006 From: renich at woralelandia.com (=?UTF-8?B?UmVuaWNoIEJvbiDEhmlyacSH?=) Date: Mon Jul 31 01:25:19 2006 Subject: [linux-audio-dev] Re: Akai's MPC4000 Sampler/Workstation Open Source Project In-Reply-To: <1154184566.9274.1053.camel@c80-216-124-251.cm-upc.chello.se> References: <44C90DAF.1070906@woralelandia.com> <200607271651.34122.gene.heskett@verizon.net> <44C94D92.1000308@woralelandia.com> <44CA5796.1050706@woralelandia.com> <1154122072.9274.981.camel@c80-216-124-251.cm-upc.chello.se> <44CAE8B9.2010800@woralelandia.com> <1154184566.9274.1053.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <44CD942C.7060404@woralelandia.com> http://www.mpc-forums.com/search.php?sid=529d3dd024d301f3d39029d1a1aefc8c that is the search form. There are several bugs. Well, you may be right in many ways. But, I think we can't stop and say: "oh, well. let's just drop the stupid quest". I think Linux was made in a similar way. I see linux as a major achievement. So, even if our project may never be as big as Linux, well, it will be an achievement. Jens M Andreasen wrote: > On Fri, 2006-07-28 at 23:48 -0500, Renich Bon ?iri? wrote: > > >> Well, the system has some major, important bugs. You could search a list >> of it on the unnofficial support forum, www.mpc-forums.com, since akai >> doesn't even have a bug tracking system, at least outside. >> >> > > Ehh ... I looked around a little in: > > Exchange tips and tricks for the Akai MPC4000 > 26864 Posts, 3600 Threads > > Is that the one? There is no search function in the forum, and quite a > low noise to content ratio. I can understand if akai is not willing to > manually browse through it all ... > > I found one report of a "missing file", but nobody chiming in with a "me > too", so there is no pattern there to follow. On the surface, that > report could also look like a "dog ate my homework" :-) > > >> The last version was released 1.5 years ago. The update has a great >> number of bugs still in it. This bugs could be corrected easily, the >> developers say, but they haven't been corrected. >> >> > What developers, akai? Open source advocates? > And again, what bug? Saying "a great number" is hard to follow up on. > > In the forum I see many suggestions that could be compiled into some > kind of wish-list. I would recommend that those people pick up some > abondoned PC from the garbage bin, install Linux, and then join us > here. > The chance of akai open sourcing their application is next to nil. They > would (and should) consider their knowhow to be trade-secrets, which > means that everything would be under an NDA. Furthermore, it would also > be riddled with licensed patents, so of very little use to us. > > That the OS (or application) is not being updated is not nescesarily a > bad thing. It might be so that the real bugs have been ironed out and > compliance with specifications have been achieved. For that matter, the > OS for my hardware synthesizer haven't been updated since late '84 (or > was that early '85?) The OS misinterpreted an "all-notes-off" to be a > "system-reset", which was the end of fun with inter-operability. Despite > that there are no further updates after that, I am still happy and I use > it every day :-) > > > >> Support from akai is very strange, you do have a support@akaipro.com >> email, but they usually just say that akai has nothing to do with it and >> that you should forget it. >> >> The hardware is great... the service isn't... they could be so >> successful,.. >> > > It's a $3K unit! If they have managed to ship, say 3000 units, they > would be close to (or beyond) break-even. My guess is, from an > accountants POV, that they are successful. > > High profiled synthesizers are like Lambourginis and Ferraris: Everybody > knows what they look like and what they can do, but only the few select > can afford to actually own one and use it. Talking of which: Porshe > still haven't fixed the bug in the back-suspension of the 911 > Carrera ... > > () > -------------- next part -------------- A non-text attachment was scrubbed... Name: renich.vcf Type: text/x-vcard Size: 390 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060731/220aead6/renich.vcf