linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] more commandline options

[Vladimir S. <ha...@so...>]

Mark,

Here is a patch for command line options.
Now, you can specify alsa card or jack playback channels or both.
If your LS is built without jack support jack options will be ignored.
If you do have jack support and you do not specify any playback channels 
it will not connect automatically and you will have to do it manually.
If you specify channels it will try if it fails you can still connect 
manually.
If jack is not running it will fall back to alsa and will try to use 
either specified card or default (0,0).
If card is specified but jack channels are not, jack will not be 
connected to even if it is running.

Please let me know if there are any problems.
BTW, with jack i can not get my LS to work correctly. It sounds out of 
tune . . .
Without jack everything works good. Have you had any similar problems?

Regards,
Vladimir.

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Vladimir S. <ha...@so...>]

Steve,

Well the situation is not worse, but it is different.
Traditionally, the users were not in control of their software.
So if format is closed and "secure" and application requires a usb plug 
to open those files and application does not provide a way for the user 
to export "secure" files into "insecure" files then the users will 
either not be able to redistribute the data or they'll have to write the 
application to do so.
Now the situation is changing because applications become more available 
and users are more in control.

In reality, true security does not exist here at all. Microsoft and 
other proprietary software vendors keep putting "licensing features" in 
their software, but as we move away from proprietary software we are at 
square one on licensing . . .

What can sample producers do? One thing they can certainly do is to 
create samples so big that they can not be downloaded in reasonable 
time. Say instead of CDs package them on DVDs.
Then stealing will be limited to those folks who know each other 
personally and exchange those DVDs.
This will continue to happen for as long as we live, i don't think we 
can do anything about that.

In reality, if you are doing serious business, you will not be able to 
do it alone. As soon as you are not alone, you'll not be able to use 
stolen samples. You project manager is going to know what software you 
are using, what sample you are using, etc,etc. Other people would know. 
It'll probably not be your personal money so why steal?
If it's a one man project it probably is not that big of a deal if a 
small percentage of people swap DVDs . . .
Comapnies who produce samples should perhaps consider renting samples 
for those folks to extract some revenue out of them as well.

Regards,
Vladimir.

Steve Harris wrote:

>On Sun, Feb 01, 2004 at 02:41:44 -0500, Vladimir Senkov wrote:
>  
>
>>Steve,
>>
>>Even with license server(s), usb plug(s), etc, etc. I don't think this 
>>is possible.
>>Because the person who has license one way or another (usb plug, license 
>>server, etc) could always extract the sample from it's "secure" format 
>>and save it into a regular gig.
>>    
>>
>
>Agreed, after giving it some more though I dont think its possible - the
>user controls the hardware thats playing back the data, so you cant keep
>it from them.
>
>OTOH the situation is not worse than it is on Mac/Win.
>
>- Steve 
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>  
>

Re: [Linuxsampler-devel] new to the list

[Mark K. <mar...@co...>]

On Sun, 2004-02-01 at 07:06, Michiel Post wrote:
> Hi LS group, 
> 
> I´m new to this group so let me introduce myself to you guys.
> 
> I am Michiel Post, owner of Post Musical Instrruments, a small company
> that makes sample libraries of pianos, harpsichords, organs etc. Our
> company is based in Amsterdam, since 1999. We make libraries in all
> current sampler formats (Giga, Halion, Kontakt, EXS24, Akai, SF2,
> Kurzweil etc). And we just have a Native Instruments KOMPAKT plug-in
> version of our PMI Bosendorfer 290 out. I have  multiple PC´s running
> audio applications (all windows machines) and a few PC´s for office
> tasks. Also I have a Mac G4 and a G5 Mac for specific things, mainly
> testing libraries in Logic and OSX environments. 

Michael,
   Welcome. I am familiar with your work and your gig files are top
rate. We are happy and lucky to have you here. We look forward to your
participation and your unique views on what we are trying to accomplish
here, both for the program as well as for the library developers.

   Some of what I say below may scare you at first. Please know that
it's not my intention to drive you or any other library vendor away.
Rather we need you to make this all more successful. None the less, this
is not the Windows world and things will work differently, or so I
think.

   Good luck in your exploration!

> 
> I am very excited to try out Linux and LinuxSampler. I will gladly get
> involved in the developement of LinuxSampler. I am not a programmer
> but I have a long and vast experience with samplers and computers so I
> hope I can add valuable experiences and feedback. 

I am a tester and not a programmer also. I have found this group of
developers, as is true for most Linux/Open Source groups, to be very
user oriented. I think you'll enjoy it immensely when you request s new
feature and it's in the program and working on your computer in 24
hours. 

Currently I have about 400 gig files. Most that I have tested are now
playing pretty well on LS, sans articulations, filters, LFOs and
envelopes. It's a good start, but we can go so much farther!

> 
> I will distribute my libraries to developers of the LS app so that
> specific features can be checked by everybody (and you can make some
> music while working too!'). I have a modest Pentium4 1.8 GHz box all
> set up under Linux for tests and will add a modest Celeron and Athlon
> later if needed. 
> 
> I´m thinking of writing a list of features that I think would be of
> interest for LS. We can discuss this and see what good it brings. 

This would be great.
<SNIP>
> The total cost of ownership matters less for well paid Hollywood guys
> than simple home users! 
<SNIP>
> The true potential of LS for me would be to reach every Windows box
> user and being able to offer something that can do much more than any
> Windows machine offers for free. For this LS has to be delivered in a
> way that installs on all machines with relative ease.

Well said. These are great goals and not out of line with what folks
here are thinking.
> 
> There are some some drawbacks that your discussions so far have
> already talked about. One is the need for specific audiodrivers for
> all the different audiocards that are out there in the market.  Don´t
> forget that all windows users have installation  cd´s that come with
> the audiocard with specific installers for their win/mac audio cards.
> Installing some specific Linux driver for a card (after a distro is on
> the machine) shouldn´t be too problematic. Most home  users definitly
> have internet access on their music machines, hence downloading a
> driver is childplay, compared to other things they must do to keep
> their machines running. 

Well, yes and no. I think that if you have not run Linux audio yet you
are likely in for a bit of a shock as to how much yo have to do to get
it to work well, especially if you have a more advanced sound card as we
expect that many GSt users will.

A few of use are working in the background a bit on how to help with
some of this, but the truth is that should a GSt user who runs today
with a Creamware card come to try out a LS demo he will find that he
simply cannot do it for lack of a Linux sound driver. 

> 
> The other obvious drawback is that their other application are running
> under Windows or Mac and that these apps would no longer be available
> when Linux is active on their machines. This is a problem. You see
> when somebody has developed a certain way of working, several
> applications are involved to create the final result. LS should
> somewhere intergrate in the already existing way of working. 

Hence I think the hope that a Windows-based VSTi front end with LS
running on a separate box would make that less of a problem. None the
less, there will certainly be issues like this.

> 
> If Linux could work under a Win/Mac OS shell, people could just launch
> LS from inside their existing environment. This will not work for
> obvious reasons, one is that the total CPU load of running two OS´s
> will be really demanding I guess. So limiting LS to standalone
> machines, clusters and networking environments makes sense in that
> light. But how doe one integrate in the existing environment?

VSTi?

> 
> Now about our wish to have superior Copy Protection implemented in new
> techonolgy to protect our intellectual property against piracy. Most
> of the sample library developers that I know are seriously hurt by
> piracy. Some have experienced that for every disk they seel over 20
> illegal copies are beeing used. Some even have worst percentages. The
> only way we now protect our work is when the sounds are wrapped in a
> so called rompler (the sounds are provided in a sampler playback
> software app that limits all wavedata access and has a good
> challenge-response authorization method) like th NI KOMPAKT player
> that I use. 

I think this is going to be an issue. I work in the Intellectual
Property part of the semiconductor industry for a living selling things
like 1394 designs to folks making chips. I'm quite familiar with the
reasons for having IP, and for protecting IP, and I agree with nearly
all of them.

On the other hand, let's look at GS3 (or any program) and how it
protects you. You are used to the idea that the user only has executable
programs and does not have the source code. The Open Source arena is
quite different. People will be downloading source code and building it
themselves to run LS on their system. While we can write this source so
that it won't extract your wave files and write them into a file, there
is no guarantee that a smart individual won't take the source code and
do exactly what you are afraid of. 

This is a big problem, as I see it.

> This limits the possibilities. The other measure that works rather
> well is watermarking. The drawback of watermarking is that the
> watermark makes it possible to prove somebody used your sound, but
> it´s impossible to track down each illegal copy and verybody that uses
> my sounds and start procecution of offenders.

Agreed. Very difficult, and possibly very expensive.

These discussions have occurred other places, like Northern Sounds,
before. I personally come down on the side that if your TAM (total
available market) became 10 times as large you might realistically sell
2-3 times as much as you do today. This would be good for you, overall.

Unfortunately, there will always be bad folks who want to cheat, and
none of these normal means will protect you 100% I fear. How to proceed
will always be up to you the developer.
> 
> We are thinking of a new system which would help a lot when it can be
> implemented in some way in Linux. The basic idea is to make sure that
> the datafile that we provide to be used by the sampler is locked in a
> way to one machine or one user. The best method would be to lock the
> file to the hard drive on which it is installed. Once the file is
> there it can be used. When it´s copied (and the Hard drive hardware 
> ID is missing) the file is messed up and encrypted. In order to do
> this we would some new method of data encryption I guess, so I drop
> this question here to see if anyone has ideas.

No, I think you are still subject to someone taking the source code and
modifying it to write your wave files out unencrypted from a properly
licensed machine.

There are much better ways to do this sort of locking with Linux. Look
into flexlm licensing. Watermark the library if you feel the need so
that I get my own copy. Use the watermark information to generate a flex
encrypted key for me. I then run flexlm and unlock the appropriate use. 

None the less, this can be circumvented by simply taking the source code
and doing things to it. The problem you'll have here is similar to what
you'd have in the Windows world if you could NOT trust Tascam to keep
the data safe in the program and worried about them giving your IP away.
I think here with source code there are no perfect answers that I know
about. 

I look forward to hearing from others.
> 
> That´s it for now. I look forward hearing your thoughts.
> 
Great to have you here. Not trying to scare you, but rather to educate
(both you and I!) before you get too involved and then get
disappointed.)

With best regards,
Mark

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Steve H. <S.W...@ec...>]

On Sun, Feb 01, 2004 at 02:41:44 -0500, Vladimir Senkov wrote:
> Steve,
> 
> Even with license server(s), usb plug(s), etc, etc. I don't think this 
> is possible.
> Because the person who has license one way or another (usb plug, license 
> server, etc) could always extract the sample from it's "secure" format 
> and save it into a regular gig.

Agreed, after giving it some more though I dont think its possible - the
user controls the hardware thats playing back the data, so you cant keep
it from them.

OTOH the situation is not worse than it is on Mac/Win.

- Steve 

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Vladimir S. <ha...@so...>]

Steve,

Even with license server(s), usb plug(s), etc, etc. I don't think this 
is possible.
Because the person who has license one way or another (usb plug, license 
server, etc) could always extract the sample from it's "secure" format 
and save it into a regular gig.

You could try to put something like a signature into a sample so that it 
will be inaudible but still detectable in the end product. So that if 
someone produces a track you could tell if your sample was used there or 
not.
But with all the filtering, effects and compression it is close to 
impossible . . .

Regards,
Vladimir.

Steve Harris wrote:

>Great news, Benno :)
>
>On Mon, Jan 26, 2004 at 01:12:20 +0100, be...@ga... wrote:
>  
>
>>On the other hand sample library producers have concerns about piracy, so
>>they are interested if sample content can be protected while keeping
>>the sampler open. We should think about those issues over the long term.
>>    
>>
>
>Sadly I dont think thats possible - encryption/security always relies on
>some secret, and there are no secrets in (purely) open source software.
>
>An option might be a closed-source licence server (for networks of
>machines), best would be if we could use an existing, trusted UNIX licence
>server, like the one matlab uses.
>
>Even then its really hard.
>
>- Steve
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>  
>

[Linuxsampler-devel] new to the list

[Michiel P. <mp...@xs...>]

Hi LS group,=20

I=B4m new to this group so let me introduce myself to you guys.

I am Michiel Post, owner of Post Musical Instrruments, a small company =
that makes sample libraries of pianos, harpsichords, organs etc. Our =
company is based in Amsterdam, since 1999. We make libraries in all =
current sampler formats (Giga, Halion, Kontakt, EXS24, Akai, SF2, =
Kurzweil etc). And we just have a Native Instruments KOMPAKT plug-in =
version of our PMI Bosendorfer 290 out. I have  multiple PC=B4s running =
audio applications (all windows machines) and a few PC=B4s for office =
tasks. Also I have a Mac G4 and a G5 Mac for specific things, mainly =
testing libraries in Logic and OSX environments.=20

I am very excited to try out Linux and LinuxSampler. I will gladly get =
involved in the developement of LinuxSampler. I am not a programmer but =
I have a long and vast experience with samplers and computers so I hope =
I can add valuable experiences and feedback.=20

I will distribute my libraries to developers of the LS app so that =
specific features can be checked by everybody (and you can make some =
music while working too!'). I have a modest Pentium4 1.8 GHz box all set =
up under Linux for tests and will add a modest Celeron and Athlon later =
if needed.=20

I=B4m thinking of writing a list of features that I think would be of =
interest for LS. We can discuss this and see what good it brings.=20

I had the pleasure to meet with Benno during the NAmm show in LA and =
must say I=B4m very excited about the LS project and the fact that this =
works under Linux, which would open up a whole range of new =
possibilities.=20

One of them is a stand alone black box that would function as a sound =
module where our sample libraries can be pre-installed. For this I will =
build a kind of prototype as soon as the software is available and =
examine what possibilities such a unit would have in the market.=20

=20

One of the things that strikes me in this project is that while you are =
alreeady talking about a roadmap for the future of LS developement you =
don=B4t seem to have a clearly defined group of people that you want to =
reach with the LS project.=20

I read that you have set a goal to get LS in Hollywood studios, to prove =
that playing large scale orchestral arrengements in a profesional =
envirnment is very well possible without using Windows or MAc OS on the =
machine.=20

Somewhere else I read that you want to get as many users away from the =
Windows platform.

Let me go into these goals from the point of a sound library developer.

The target of getting LS in Hollywood is an easy goal in my opinion. =
There are not so many of these producers and composers out there to =
begin with. Replacing a stand alone playback only machine with another =
one that does exacttly the same is an easy choice. Speciqally if the new =
one is simpler. If all 1000 composers would get a linux box and save a =
few 100 dollars on linux boxes then your goal is achieved. This =
shouldn=B4t be the ultimate goal I think. Look where this goal got =
TASCAM with GST. Their app is so complicated for a large audience (and =
expensive too) that the total world penetration is very low, maybe even =
limited to the audience of Hollywood composers and alikes, all in all =
around 10.000 worldwide. This is also my audience when I release =
giga-format libraries. One of the main advanteges of LS is that it will =
be more or less free. This makes it possible to become used by =
100.000=B4s maybe millions instead of a few 10000 people. Here  is the =
big power of the LS application in my view. Not just in atracting a few =
people in Hollywood away from Windows. The total cost of ownership =
matters less for well paid Hollywood guys than simple home users! If =
you=B4re already working in a studio replacing a few boxes and saving =
several 100=B4s is not a huge difference in their budgets. See what =
Apple=B4s G5=B4s are doing. They are expensive as hell and sell better =
than any machine they made before. Money is not so much an issue there. =
The true potential of LS for me would be to reach every Windows box user =
and being able to offer something that can do much more than any Windows =
machine offers for free. For this LS has to be delivered in a way that =
installs on all machines with relative ease.

There are some some drawbacks that your discussions so far have already =
talked about. One is the need for specific audiodrivers for all the =
different audiocards that are out there in the market.  Don=B4t forget =
that all windows users have installation  cd=B4s that come with the =
audiocard with specific installers for their win/mac audio cards. =
Installing some specific Linux driver for a card (after a distro is on =
the machine) shouldn=B4t be too problematic. Most home  users definitly =
have internet access on their music machines, hence downloading a driver =
is childplay, compared to other things they must do to keep their =
machines running.=20

The other obvious drawback is that their other application are running =
under Windows or Mac and that these apps would no longer be available =
when Linux is active on their machines. This is a problem. You see when =
somebody has developed a certain way of working, several applications =
are involved to create the final result. LS should somewhere intergrate =
in the already existing way of working.=20

If Linux could work under a Win/Mac OS shell, people could just launch =
LS from inside their existing environment. This will not work for =
obvious reasons, one is that the total CPU load of running two OS=B4s =
will be really demanding I guess. So limiting LS to standalone machines, =
clusters and networking environments makes sense in that light. But how =
doe one integrate in the existing environment?

Now about our wish to have superior Copy Protection implemented in new =
techonolgy to protect our intellectual property against piracy. Most of =
the sample library developers that I know are seriously hurt by piracy. =
Some have experienced that for every disk they seel over 20 illegal =
copies are beeing used. Some even have worst percentages. The only way =
we now protect our work is when the sounds are wrapped in a so called =
rompler (the sounds are provided in a sampler playback software app that =
limits all wavedata access and has a good challenge-response =
authorization method) like th NI KOMPAKT player that I use.=20

This limits the possibilities. The other measure that works rather well =
is watermarking. The drawback of watermarking is that the watermark =
makes it possible to prove somebody used your sound, but it=B4s =
impossible to track down each illegal copy and verybody that uses my =
sounds and start procecution of offenders.

We are thinking of a new system which would help a lot when it can be =
implemented in some way in Linux. The basic idea is to make sure that =
the datafile that we provide to be used by the sampler is locked in a =
way to one machine or one user. The best method would be to lock the =
file to the hard drive on which it is installed. Once the file is there =
it can be used. When it=B4s copied (and the Hard drive hardware  ID is =
missing) the file is messed up and encrypted. In order to do this we =
would some new method of data encryption I guess, so I drop this =
question here to see if anyone has ideas.

That=B4s it for now. I look forward hearing your thoughts.

=20

Michiel Post

=20

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.553 / Virus Database: 345 - Release Date: 18-12-2003

Re: [Linuxsampler-devel] ADSDR 6th try

[Vladimir S. <ha...@so...>]

Mark,

Here is a patch to add --outputcard option.
It is against latest CVS and isolated from any other patches.
I'll look into adding a jack option you suggested tomorrow.
Do you think we need to change the logic that LS follows when opening audio?
Currently, it tries jack first and if that fails it opens alsa.
Should we skip jack alltogether if --outputcard option is specified?

Regards,
Vladimir.


Mark Knecht wrote:

>On Sun, 2004-01-18 at 17:22, Vladimir Senkov wrote:
>  
>
>>Mark,
>>Last e-mail :)
>>
>>Few small things here but mostly to try out a hack to implement 
>>"re-sustain" effect we talked about earlier.
>>For now, just a "proof of concept", it will be coded differently. for 
>>now i just created a global because there is no easy way to link sustain 
>>to voices after ProcessNoteOff().
>>Let me know how it feels with different samples. My impression is that 
>>it sounds fairly accurate with samples that have infinite sustain 
>>disabled (such as that free Steinway sample i'm using), but perhaps a 
>>bit too strong with infinite sustain samples such as Church Organ for 
>>example.
>>I'm thinking about making that second sustain stage non-infinite just 
>>like decay2 even for samples with infinite sustain. Any thoughts on this?
>>I'll test it with GS next weekend to see how it does it with different 
>>samples.
>>
>>Regards,
>>Vladimir.
>>
>>PS: patch is not incremental. Apply to latest CVS.
>>    
>>
>
>Vladimir & Christian,
>   OK, I've installed today's CVS with ADSDR6. It seems to be working
>fine so far. It correctly determines if Jack is running. If Jack is not
>running it does what it did before. However, I needed to edit
>audioio.cpp before and what I needed to edit appears to have moved.
>Could I make my first simple enhancement request? Could we have a
>command line option to tell it which sound card to use? Earlier I was
>changing plughw:0 to plughw:1. Could the number be changed to be a
>command line option? (--card "plughw:1")
>
>  If Jack is running it connects to the the Jack server, but it doesn't
>connect the audio path automatically. Could I make my second request to
>have a command line option to make this connection? (--jack-ch
>"playback_1, playback_2" - I.e. don't forget stereo vs. mono...) 
>
>   Also, I think it would be helpful to have LS print some sort of
>revision info when it starts. I have so many versions now I'd like to be
>sure when I install a new version that I'm really using it. ;-)
>
>   OK, with that all behind me it appears that LS is working well with
>Jack. No clicks of pops so far. The only negative thing I've noticed so
>far is that with a lot of notes playing I seem to be getting a lot of
>hiss in the background. As the notes die away the hiss goes away, so it
>appears to be part of the sample, but in LS I *think* I'm getting a lot
>more hiss now? Could this be part of the ADSDR edit, or could it have
>something to do with using Jack?
>
>   I need to go back and find the code that moved so that I can use my
>HDSP 9652 without Jack, or wait for you all to add the card choice
>enhancement. 
>
>   I'll start playing with more gigs and see what I come up with, but my
>first impression is very positive.
>
>Cheers,
>Mark
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>  
>

Re: [Linuxsampler-devel] ADSDR 6th try

[Vladimir S. <ha...@so...>]

Christian,

I *think* it is 99% done. Keep in mind my inexperience with digital audio
software though. I'll clean it up this weekend and send you the result.

I'm not 100% sure it acts exactly like Gst but i tried to follow your emails
when implementing it.
I've added an ascii diagram describing the state machine. So if you don't
have time to review the code but could take a quick look at that diagram
that'd be great. Because if fundamentals are wrong it will not be worth your
time reviewing the code.

I have a few questions . . .
First one is about the "double sustain". Are we going to do that? If so, how
. . . i've hacked that in using a global and it seems to work ok, but i'd
like feedback on that.
Second question is about post attack hold. I was going to use
gig::Sample::SamplePeriod to calculate post attack hold period but it is
only 32 bits and that's in nanoseconds. 32 bits seems way too short for
nanoseconds. So i was not sure if i was missing something or not. Currently,
the post attack hold period is calculated incorrectly but i'm going to fix
it tonight or tomorrow at the latest.
Last question is about Release coefficient calculation for samples without
infinite sustain. I'm currently calculating it only once before the
trigger(). Sustain level is used in that calculation.
But if Decay2 has already lowered the level from sustain level, then the
Release coefficient is not updated and will actually produce a shorter
release phase. This sould not produce clicks because decay2 has already
lowered the level (if it hasn't lowered it enough then release phase will be
long enough).
I can't find any document to clarify if that is correct interpretation or
not. It makes sense, but if release phase must really be fixed in time
regardless of when it starts in decay2 phase, then coefficient will need to
be calculated before Release(), not before Trigger(). It's not a problem to
do it that way, but i'm just not sure what is the right way.

Mark has also reported getting some hiss and i was hoping we could
troubleshoot that to figure out if that is related to adsdr patch or not. I
have not noticed that on my setup. Unfortunately Mark is having some
problems with alsa at the moment so we can't really troubleshoot this right
now.

I'm onto command line options.

Regards,
Vladimir.

----- Original Message -----
From: "Christian Schoenebeck" <chr...@ep...>
To: "Vladimir Senkov" <ha...@fu...>; "Rui Nuno Capela"
<rn...@rn...>
Cc: <lin...@li...>
Sent: Saturday, January 31, 2004 3:24 PM
Subject: Re: [Linuxsampler-devel] ADSDR 6th try


> Es geschah am Samstag, 31. Januar 2004 03:56 als Vladimir Senkov schrieb:
> > Any other feedback on that adsdr patch? I have a semi free weekend ahead
> > and should be able to fix bugs or rewrite it completely depending on how
> > bad it is :) Or maybe clean up the code and get it ready for check in?
> > If anyone has time to review the code that would be greately
appreciated.
>
> Vladimir, Mark: Is the EG patch already finished? Means does the EG act
like
> the original Gst one? I'm currently busy, but I'll have a look at it next
> week if you think the patch is already complete.
>
> > Also, if there are no objections, i could look into those enhancement
> > requests that Mark made at the bottom of the e-mail. Should be pretty
> > straight forward i assume, but i don't want to do that if someone is
> > already looking into it :)
>
> You mean those command line options, right? If yes, I'd appreciate if
you'll
> take that task.
>
> Rui: Sorry, I'm still working on some things in the engine, but I'll start
> with the bison network interface next week.
>
> CU
> Christian
>
> P.S. these delays on this list are really annoying, maybe we should move
the
> mailing list away from sourceforge
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] ADSDR 6th try

[Vladimir S. <ha...@so...>]

Mark,

Sorry to hear about your troubles.
Have you upgraded alsa since the last time everything was working ok?
If so, could you try to go back to alsa that worked ok?
What else may have changed?

Last time you had LS running CVS had the same code as it had yesterday (i
had it saved and did a diff yesterday) so there were no checkins yet and LS
should work the same way it worked before. I think it must be something else
. . . kernel, alsa, jack . . .
Maybe it's worth trying witout jack?

Could you tell me your kernel, alsa and jack versions?
I could try that combination on my pc, but i have different hardware so it
probably will not have the same problem.

Regards,
Vladimir.

----- Original Message -----
From: "Mark Knecht" <mar...@co...>
To: <ha...@fu...>
Cc: "Linux-Sampler" <lin...@li...>
Sent: Saturday, January 31, 2004 3:29 PM
Subject: Re: [Linuxsampler-devel] ADSDR 6th try


> On Fri, 2004-01-30 at 18:56, Vladimir Senkov wrote:
> > Mark,
> >
> > Are you still getting hiss that you were getting before?
> > If so, could you try to pull LS from CVS and rebuild and test if it is
> > still there? If so, it may have something to do with jack support or
> > other non-adsdr related changes. If you are only getting that after you
> > apply adsdr patch then it must be something that came with the patch and
> > i'll be happy to investigate.
> >
> > Any other feedback on that adsdr patch? I have a semi free weekend ahead
> > and should be able to fix bugs or rewrite it completely depending on how
> > bad it is :) Or maybe clean up the code and get it ready for check in?
> > If anyone has time to review the code that would be greately
appreciated.
> >
> > Also, if there are no objections, i could look into those enhancement
> > requests that Mark made at the bottom of the e-mail. Should be pretty
> > straight forward i assume, but i don't want to do that if someone is
> > already looking into it :)
> >
> > Regards,
> > Vladimir.
>
> Vladimir,
>    Hi. I don't know what's happening on my end, but downloading LS this
> morning and building it I seem to either get no sound at all, or I get
> sound but only after a while.
>
>    I've had some updates on this machine, so maybe its a gcc/glibc
> issue. I don't know yet. The adsdr6 patch file applies cleanly against
> today's CVS. I then edit the code in alsaio.cpp to go to 1,0 instead of
> 0,0, then ./configure and make. The code starts, looks normal, sees Jack
> if I have it running, but I get no MIDI events into it even though
> kaconnect says it's hooked up.
>
>    Sometimes after a while I see a burst of MIDI and a whole bunch of
> noise, but mostly nothing.
>
>    I'll see if I can figure this out, but it may be beyond my limited
> skills. It appears that when this happens it is taking out either all of
> Alsa or my HDSP 9652 driver. After the problem occurs in LS I'm unable
> to do anythingwith audio without a reboot. Even stopping and restarting
> Alsa isn't working.
>
>    Not a nice start to the day...
>
> Take care,
> Mark
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] ADSDR 6th try

[Mark K. <mar...@co...>]

On Fri, 2004-01-30 at 18:56, Vladimir Senkov wrote: 
> Mark,
> 
> Are you still getting hiss that you were getting before?
> If so, could you try to pull LS from CVS and rebuild and test if it is 
> still there? If so, it may have something to do with jack support or 
> other non-adsdr related changes. If you are only getting that after you 
> apply adsdr patch then it must be something that came with the patch and 
> i'll be happy to investigate.
> 
> Any other feedback on that adsdr patch? I have a semi free weekend ahead 
> and should be able to fix bugs or rewrite it completely depending on how 
> bad it is :) Or maybe clean up the code and get it ready for check in?
> If anyone has time to review the code that would be greately appreciated.
> 
> Also, if there are no objections, i could look into those enhancement 
> requests that Mark made at the bottom of the e-mail. Should be pretty 
> straight forward i assume, but i don't want to do that if someone is 
> already looking into it :)
> 
> Regards,
> Vladimir.

Vladimir,
   Hi. I don't know what's happening on my end, but downloading LS this
morning and building it I seem to either get no sound at all, or I get
sound but only after a while. 

   I've had some updates on this machine, so maybe its a gcc/glibc
issue. I don't know yet. The adsdr6 patch file applies cleanly against
today's CVS. I then edit the code in alsaio.cpp to go to 1,0 instead of
0,0, then ./configure and make. The code starts, looks normal, sees Jack
if I have it running, but I get no MIDI events into it even though
kaconnect says it's hooked up.

   Sometimes after a while I see a burst of MIDI and a whole bunch of
noise, but mostly nothing.

   I'll see if I can figure this out, but it may be beyond my limited
skills. It appears that when this happens it is taking out either all of
Alsa or my HDSP 9652 driver. After the problem occurs in LS I'm unable
to do anythingwith audio without a reboot. Even stopping and restarting
Alsa isn't working.

   Not a nice start to the day...

Take care,
Mark

Re: [Linuxsampler-devel] ADSDR 6th try

[Christian S. <chr...@ep...>]

Es geschah am Samstag, 31. Januar 2004 03:56 als Vladimir Senkov schrieb:
> Any other feedback on that adsdr patch? I have a semi free weekend ahead
> and should be able to fix bugs or rewrite it completely depending on how
> bad it is :) Or maybe clean up the code and get it ready for check in?
> If anyone has time to review the code that would be greately appreciated.

Vladimir, Mark: Is the EG patch already finished? Means does the EG act like 
the original Gst one? I'm currently busy, but I'll have a look at it next 
week if you think the patch is already complete.

> Also, if there are no objections, i could look into those enhancement
> requests that Mark made at the bottom of the e-mail. Should be pretty
> straight forward i assume, but i don't want to do that if someone is
> already looking into it :)

You mean those command line options, right? If yes, I'd appreciate if you'll 
take that task.

Rui: Sorry, I'm still working on some things in the engine, but I'll start 
with the bison network interface next week.

CU
Christian

P.S. these delays on this list are really annoying, maybe we should move the 
mailing list away from sourceforge

Re: [Linuxsampler-devel] liblscp: A LinuxSampler Control Protocol implemetation

[Christian S. <chr...@ep...>]

Es geschah am Mittwoch, 28. Januar 2004 13:45 als Rui Nuno Capela schrieb:
> OTOH bison/yacc/flex/whatever are a total mistery to me, so someone else
> has to come for the rescue :)

No problem, I just have to finish some things in the engine I'm currently 
working on and I think at the weekend I will have the time to write a bison 
solution for the engine's network interface. Or what's your opinion Benno? 
Should we just use Ruis lib for the moment? I still suggest to use it on 
client (GUI) side only and using bison on LS side.

CU
Christian

Re: [Linuxsampler-devel] ADSDR 6th try

[Vladimir S. <ha...@so...>]

Mark,

Are you still getting hiss that you were getting before?
If so, could you try to pull LS from CVS and rebuild and test if it is 
still there? If so, it may have something to do with jack support or 
other non-adsdr related changes. If you are only getting that after you 
apply adsdr patch then it must be something that came with the patch and 
i'll be happy to investigate.

Any other feedback on that adsdr patch? I have a semi free weekend ahead 
and should be able to fix bugs or rewrite it completely depending on how 
bad it is :) Or maybe clean up the code and get it ready for check in?
If anyone has time to review the code that would be greately appreciated.

Also, if there are no objections, i could look into those enhancement 
requests that Mark made at the bottom of the e-mail. Should be pretty 
straight forward i assume, but i don't want to do that if someone is 
already looking into it :)

Regards,
Vladimir.

Mark Knecht wrote:

>On Sun, 2004-01-18 at 17:22, Vladimir Senkov wrote:
>  
>
>>Mark,
>>Last e-mail :)
>>
>>Few small things here but mostly to try out a hack to implement 
>>"re-sustain" effect we talked about earlier.
>>For now, just a "proof of concept", it will be coded differently. for 
>>now i just created a global because there is no easy way to link sustain 
>>to voices after ProcessNoteOff().
>>Let me know how it feels with different samples. My impression is that 
>>it sounds fairly accurate with samples that have infinite sustain 
>>disabled (such as that free Steinway sample i'm using), but perhaps a 
>>bit too strong with infinite sustain samples such as Church Organ for 
>>example.
>>I'm thinking about making that second sustain stage non-infinite just 
>>like decay2 even for samples with infinite sustain. Any thoughts on this?
>>I'll test it with GS next weekend to see how it does it with different 
>>samples.
>>
>>Regards,
>>Vladimir.
>>
>>PS: patch is not incremental. Apply to latest CVS.
>>    
>>
>
>Vladimir & Christian,
>   OK, I've installed today's CVS with ADSDR6. It seems to be working
>fine so far. It correctly determines if Jack is running. If Jack is not
>running it does what it did before. However, I needed to edit
>audioio.cpp before and what I needed to edit appears to have moved.
>Could I make my first simple enhancement request? Could we have a
>command line option to tell it which sound card to use? Earlier I was
>changing plughw:0 to plughw:1. Could the number be changed to be a
>command line option? (--card "plughw:1")
>
>  If Jack is running it connects to the the Jack server, but it doesn't
>connect the audio path automatically. Could I make my second request to
>have a command line option to make this connection? (--jack-ch
>"playback_1, playback_2" - I.e. don't forget stereo vs. mono...) 
>
>   Also, I think it would be helpful to have LS print some sort of
>revision info when it starts. I have so many versions now I'd like to be
>sure when I install a new version that I'm really using it. ;-)
>
>   OK, with that all behind me it appears that LS is working well with
>Jack. No clicks of pops so far. The only negative thing I've noticed so
>far is that with a lot of notes playing I seem to be getting a lot of
>hiss in the background. As the notes die away the hiss goes away, so it
>appears to be part of the sample, but in LS I *think* I'm getting a lot
>more hiss now? Could this be part of the ADSDR edit, or could it have
>something to do with using Jack?
>
>   I need to go back and find the code that moved so that I can use my
>HDSP 9652 without Jack, or wait for you all to add the card choice
>enhancement. 
>
>   I'll start playing with more gigs and see what I come up with, but my
>first impression is very positive.
>
>Cheers,
>Mark
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>  
>

RE: [Linuxsampler-devel] Segfault

[Vladimir S. <ha...@so...>]

Hi,

I've seen this a few times. Every time I do I forget to do ulimit -c
....
You don't actually have to have gdb running, you can just set the
coresize to something larger than 0 (probably a lot larger :)
And then it should write a corefile on a segfault. You then can open the
corefile with gdb (you'll need ls executable that generated the core
with symbols as well).
I'll try not to forget to set the coresize from now on before running ls
(I'll just put ulimit -c in /etc/profile or something).

Regards,
Vladimir.


-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
Christian Schoenebeck
Sent: Wednesday, January 28, 2004 5:22 PM
To: lin...@li...
Subject: [Linuxsampler-devel] Segfault


Hi!

There is a segmentation fault that occurs sometimes in LS. Unfortunately

whenever it occurs on my machine I forgot to launch gdb. :/

So you could do me a big favour by running LS with gdb and sending us
the 
stack trace of the segfault to this list whenever this should happen!

CU
Christian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the
breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linuxsampler-devel mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Re: 32 layer piano demo GIG

[<be...@ga...>]

Robert is right, rar packs audio data better than other compressors.

here is unrar for Linux:

http://dag.wieers.com/packages/unrar/

cheers,
Benno
http://www.linuxsampler.org


Scrive Robert Jonsson <rob...@da...>:

> fredagen den 30 januari 2004 21.04 skrev Juhana Sadeharju:
> > From: be...@ga...
> >
> > >The guys that make the White Grand, a 32 layer piano GIG posted a demo
> > >GIG that contains only one note but all 32 layers.
> > >
> > >http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php
> > > ?ubb=get_topic;f=3;t=007077
> >
> > It is rar file. Can somebody turn the files to tar.bz2 format?
> >
> > Why people use rar? In Linux it is as odd format as hqx.
> 
> There is an unrar utility available with most distros.
> 
> Anyway, I think the reason is that rar happens to pack audio-data very well.
> 
> /Robert
> 	
> >
> > Regards,
> > Juhana
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




-------------------------------------------------
This mail sent through http://www.gardena.net

Re: [Linuxsampler-devel] Segfault

[Steve H. <S.W...@ec...>]

On Wed, Jan 28, 2004 at 11:22:15 +0100, Christian Schoenebeck wrote:
> Hi!
> 
> There is a segmentation fault that occurs sometimes in LS. Unfortunately 
> whenever it occurs on my machine I forgot to launch gdb. :/
> 
> So you could do me a big favour by running LS with gdb and sending us the 
> stack trace of the segfault to this list whenever this should happen!

You could just turn on core dumps - the core will be biggish, but means
you dont have to remeber to start it in gdb.

- Steve

Re: [Linuxsampler-devel] Re: 32 layer piano demo GIG

[Robert J. <rob...@da...>]

fredagen den 30 januari 2004 21.04 skrev Juhana Sadeharju:
> From: be...@ga...
>
> >The guys that make the White Grand, a 32 layer piano GIG posted a demo
> >GIG that contains only one note but all 32 layers.
> >
> >http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php
> > ?ubb=get_topic;f=3;t=007077
>
> It is rar file. Can somebody turn the files to tar.bz2 format?
>
> Why people use rar? In Linux it is as odd format as hqx.

There is an unrar utility available with most distros.

Anyway, I think the reason is that rar happens to pack audio-data very well.

/Robert
	
>
> Regards,
> Juhana
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] Re: 32 layer piano demo GIG

[Juhana S. <ko...@ni...>]

>From: be...@ga...
>
>The guys that make the White Grand, a 32 layer piano GIG posted a demo
>GIG that contains only one note but all 32 layers.
>
>http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php
> ?ubb=get_topic;f=3;t=007077

It is rar file. Can somebody turn the files to tar.bz2 format?

Why people use rar? In Linux it is as odd format as hqx.

Regards,
Juhana

[Linuxsampler-devel] Segfault

[Christian S. <chr...@ep...>]

Hi!

There is a segmentation fault that occurs sometimes in LS. Unfortunately 
whenever it occurs on my machine I forgot to launch gdb. :/

So you could do me a big favour by running LS with gdb and sending us the 
stack trace of the segfault to this list whenever this should happen!

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Christian S. <chr...@ep...>]

Es geschah am Dienstag, 27. Januar 2004 18:08 als Mark Constable schrieb:
> On Wed, 28 Jan 2004 02:34 am, Christian Schoenebeck wrote:
> > ... So
> > developers add new feature points (when they got new ideas / proposals),
> > branches to the tree by themselfes and put their names to a feature point
> > before they decide to implement that planned feature.
> >
> > I could write a CGI script or something to make it convenient for
> > developers.
>
> Just use a Wiki so it's generally useful for all kinds of
> docs and notes. I run http://alsa.opensrc.org and it's been
> getting 1/2 dozen edits a day now for the last few months.
> It dribbled along at 3 or 4 edits a week for a couple of
> years but now it's really cookin.

That would be nice for users, but I don't think this would be the right choice 
for the development roadmap.

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Mark K. <mar...@co...>]

On Wed, 2004-01-28 at 15:28, Robert Jonsson wrote:

> 
> If I'm not mistaken the newer CD distros do use alsa and should autoconfigure 
> quite nicely. MandrakeMove springs to mind as a distro that probably has 
> autodetect of alsa.
> 
> I imagine though that some pro-audio cards require some specific 
> configurations to get going, this might prove hard.
> But then again they are not that many so it might be possible to provide 
> specific scripts.
> 
> /Robert
> 

I have 5 machines, all with different sound cards I can try. I'm
downloading Dynebolic as we speak and will give the others a try as we
go. I'm sure there's time to solve this before LS is ready to go to a
public beta for Windows users.

It will be interesting to see how this works. For instance, my GSt
machine has two sound cards and 2 hard drives. I look forward to seeing
how far autoconfig works. I expect probably pretty well.

Cheers,
Mark

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Robert J. <rob...@da...>]

Hi,

I think this live cd business would be a very good idea, especially for a tool 
like linuxsampler that can be used stand-alone.

> Thanks Steve. That's what I think.
>
> I was trying to imagine what happens when someone sticks a CD in there
> GSt machine and reboots into Linux. I understand from other threads that
> some of these Live CD distros can find networking devices and even 1394
> devices, but I've not heard of any of them discovering specific sound
> cards and and actually bringing up Alsa automatically. So...how are
> these folks going to get Alsa running when presumably they won't even
> know how to run vi?

If I'm not mistaken the newer CD distros do use alsa and should autoconfigure 
quite nicely. MandrakeMove springs to mind as a distro that probably has 
autodetect of alsa.

I imagine though that some pro-audio cards require some specific 
configurations to get going, this might prove hard.
But then again they are not that many so it might be possible to provide 
specific scripts.

/Robert

>
> Questions - Can Alsa be reliably started from a script file after the
> machien is booted? I've never tried modprobing every command in
> modules.conf. Would it work? Could we imagine putting together some
> scripts, and even doing a bit of custom vi work for early adopters, to
> build these scripts? I don't think it will be wise to send them to
> Alsa-org and ask them to study sound card pages just to try out a demo.
> They'll never want to use Linux after that experience!) ;-)
>
> If they are doing email on another Windows machine or a Mac, and they
> put it on a floppy, could some script that's already on the Live CD be
> run from a terminal and get Alsa started?
>
> #mount /mnt/floppy
> #start Alsa
> #adjust levels (remember, not all cards work with alsamixer)
>
> Just ideas about making this work so easily that an 80 year old
> Grandmother would have a chance of getting sound out.
>
> - Mark
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Steve H. <S.W...@ec...>]

On Wed, Jan 28, 2004 at 06:45:51 -0800, Mark Knecht wrote:
> I was trying to imagine what happens when someone sticks a CD in there
> GSt machine and reboots into Linux. I understand from other threads that
> some of these Live CD distros can find networking devices and even 1394
> devices, but I've not heard of any of them discovering specific sound
> cards and and actually bringing up Alsa automatically. So...how are
> these folks going to get Alsa running when presumably they won't even
> know how to run vi?

Theres a CD distro called dynebolic (or osmething similar) that uses ALSA
IIRC.
 
> Questions - Can Alsa be reliably started from a script file after the
> machien is booted? I've never tried modprobing every command in
> modules.conf. Would it work? Could we imagine putting together some
> scripts, and even doing a bit of custom vi work for early adopters, to
> build these scripts? I don't think it will be wise to send them to
> Alsa-org and ask them to study sound card pages just to try out a demo.
> They'll never want to use Linux after that experience!) ;-) 

Yes, you can modprobe in the appropriate driver if you know what it is -
thats what alsa-conf does.

- Steve 

Re: [Linuxsampler-devel] LinuxSampler & sample library producers NAMM report

[Mark K. <mar...@co...>]

On Wed, 2004-01-28 at 01:14, Steve Harris wrote:
> On Mon, Jan 26, 2004 at 03:26:31 -0800, Mark Knecht wrote:
> >    Since not too many people have GS3 yet, and since Tascam themselves
> > show the use of a second PC as the solution for Mac users, I'd like to
> > suggest that people in the Linux community consider just how hard it
> > will be to get Northern Sound types to build and run a Linux box if
> > they've never done it before. For this reason I was thinking that we
> > might try to find a few interested people in that community that want to
> > be early adopters and then give them some extra support. 
> 
> This would be an ideal application for a CD based distro - it should be
> possbile to use the GS files mounted off a NTFS or VFAT partitiion and
> that way they wouldnt have to install anything, just reboot.
> 
> I doesnt give them a setup they can use for much else ofcourse, but it
> could be the thin end of the wedge.
> 
> - Steve
Thanks Steve. That's what I think.

I was trying to imagine what happens when someone sticks a CD in there
GSt machine and reboots into Linux. I understand from other threads that
some of these Live CD distros can find networking devices and even 1394
devices, but I've not heard of any of them discovering specific sound
cards and and actually bringing up Alsa automatically. So...how are
these folks going to get Alsa running when presumably they won't even
know how to run vi?

Questions - Can Alsa be reliably started from a script file after the
machien is booted? I've never tried modprobing every command in
modules.conf. Would it work? Could we imagine putting together some
scripts, and even doing a bit of custom vi work for early adopters, to
build these scripts? I don't think it will be wise to send them to
Alsa-org and ask them to study sound card pages just to try out a demo.
They'll never want to use Linux after that experience!) ;-) 

If they are doing email on another Windows machine or a Mac, and they
put it on a floppy, could some script that's already on the Live CD be
run from a terminal and get Alsa started?

#mount /mnt/floppy
#start Alsa
#adjust levels (remember, not all cards work with alsamixer)

Just ideas about making this work so easily that an 80 year old
Grandmother would have a chance of getting sound out.

- Mark

[Linuxsampler-devel] liblscp: A LinuxSampler Control Protocol implemetation

[Rui N. C. <rn...@rn...>]

Hi benno et al.

A couple of weeks ago I've sent here a note about my early LSCP
(LinuxSampler Control Protocol) implementation, which I've named liblscp.

I've been kind of idle while waiting for comments about it, before going
any further, into GUI development that is.

You can check it out from:

    http://www.rncbc.org/ls/

Christian suggested that the parser should be improved towards a
yacc/bison solution, but I think that for a preliminar and working
implementation, a simple and crude parser suffices (with the supplied one,
which is strtok based, nothing can get simpler :), at least as the current
protocol draft is about.

The way liblscp is designed and in it's current implementation, which is
just a wrapper to socket communication threading, there's no tie to the
parsing method whatsoever. As the parsing should be accomplished at server
callback context, it is of the server responsability to choose whatever
mechanism it pleases to parse each client request.

However, the helper functions supplied in lscp_parser.c are already
available shall we take the hands-on approach. OK, a bunch of hardcoded
if-else's is implied but I cannot find better solution, in code-path
performance I mean ;) If you look at server_callback function on
lscp_server_test.c you know what I'm arguing about ;) Note that all the
tests to parse every possible client request are already there, at least
as of current LSCP document draft.

OTOH bison/yacc/flex/whatever are a total mistery to me, so someone else
has to come for the rescue :)

Bottom line is, I'm eager to start some GUI code ;) and I think that it
would be nice to start the server-side callback code ASAP and integrate it
on linuxsampler.

Again, can't wait for your comments.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...