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

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

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

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

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

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

Don't worry, I know that Qt/Windows is still not GPL and this hinders
 a bit the spreading of GPLed Qt apps on Windows since a commercial
license is required.
Cygwin is not fleasible and too messy IMHO, and the independent
Qt/GPL project has probably not achieved maturity yet so I guess
the best way to go is to use the commercial Qt/Windows version.
Anyway we will find a solution which can be either letting some that
owns a Qt commercial license compiling the app for us or perhaps
let one of the companies I work for buying one or we can raise some
funds to pay for a license.
As said development can be done entirely on Linux so for now we don't
need to worry about it.

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


Scrive Christian Henz <ch...@gm...>:

> On Tue, Jan 27, 2004 at 03:26:19PM +0100, be...@ga... wrote:
> 
> > Since Rui is using Qt, recompiling on Windows/Mac is just straightforward.
> >
> 
> As long as you have a commercial license of QT3/Windows. Otherwise I think
> you'd need a Cygwin/XServer enviroment to run it. I can't really tell what
> the 
> status of the GPLed native Win32 port of QT3 is (see
> http://kde-cygwin.sourceforge.net/qt3-win32)
> 
> cheers,
> Christian Henz
> 
> 


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

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

[Christian H. <ch...@gm...>]

On Tue, Jan 27, 2004 at 03:26:19PM +0100, be...@ga... wrote:

> Since Rui is using Qt, recompiling on Windows/Mac is just straightforward.
>

As long as you have a commercial license of QT3/Windows. Otherwise I think
you'd need a Cygwin/XServer enviroment to run it. I can't really tell what the 
status of the GPLed native Win32 port of QT3 is (see http://kde-cygwin.sourceforge.net/qt3-win32)

cheers,
Christian Henz

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

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

On Tue, 2004-01-27 at 09:08, Mark Constable wrote:
> 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.
> 
> --markc

Hi,
   I really like the idea of a Wiki for more experienced users, but I'm
concerned that for new users much of the info I've tried from the Alsa
Wikis isn't correct and doesn't work, or is mostly correct but because
of the poster isn't clear or not totally correct for specific sound
cards, etc. For instance, comments about alsamixer are no longer useful
for any of the RME HDSP line of cards, but that stuff never makes it
there.

   I think that in the case of LS, where we are specifically trying to
attract people away from the Windows world, that we should take extra
special care and make sure that the Wiki contents are very accurate and
clear. The Linux mantras about RTFM and joining mailing lists are likely
to be a bad solution for a busy Windows/GS library developer who knows
nothign about Linux and is trying this as a demo.

   If this can be done in a Wiki, either automatically or by hand, then
great, but if not then I'd vote for a more controlled set of web pages
with FAQ's and instructions written and tested by the group.

   BTW - can a LS GUI not point a user right to the LS home page, or to
support? Can this work well from the Windows VSTi GUI?

Cheers,
Mark

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

[Mark C. <ma...@re...>]

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.

--markc

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

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

Hey, Benno is alive! :)

Es geschah am Dienstag, 27. Januar 2004 15:26 als be...@ga... schrieb:
> BTW: some sample library producers are still a bit sceptical and would
> like to know more about LS and its roadmap.
> Probably it would be handy to write a document or some presentation
> (powerpoint-like) of what LS is what the current state of art is and
> what our short term and long term roadmap looks like.

I already talked with Marek about that. I just didn't have the time to finish 
it due to my examinations. My idea was to make a graphical tree on the 
website with planned features, mark every feature that has been done by a 
green checkmark and features under development with a yellow symbol and 
perhaps in conjunction with the name of the developer who's currently working 
on it. That would avoid situations like Paul D. had recently when somebody 
else already worked on the same feature without knowing it. 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.

> > I should be able to contribute at least every other weekend at this
> > point.
>
> Excellent !
> I hope to get back into LS development with full force soon too :-)

loflol :)))

How expandible is "soon" ? ;)

CU
Mr. Patience

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

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

Mark keep in mind that GSt shows you mono voice count while LS shows you
stereo voice count.
So be sure to multiply LS  voices by two when comparing them with
GSt voices.
So basically 12 LS voices means 24 GSt voices.
Of course with release samples voice count will go up in LS but as said
the LS streaming engine is powerful enough to deliver the performance
which is comparable to GSt.

BTW: just back from NAMM, grat show, had interesting meetings regarding LS
will tell you guys more here on the list tomorrow.
I'm still tired of a total of 24h trip + 9h of time lag so I need to
get some sleep.

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





Scrive Mark Knecht <mar...@co...>:
> 
> Currently, that piano piece uses about 90 voices max in GSt, while the
> same piece uses only 10-12 voices in LS today. With no release samples
> you would not expect a piano (without sustain) to every use more than 10
> notes, and indeed it doesn't. However, once release samples are included
> the faster melodic runs can end up with many voices active in the
> release state with just a few new notes in the key press state. (Active
> state? Note on state? What term should I use?)
> 
> I think that doing very much benchmarking before release samples are
> included is only going to lead to doing it again. In the piano ogg
> above, what you hear from LS today is only 10-15% of what GSt is doing
> with the same MIDI file.
> 
> - Mark


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

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

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

Scrive Vladimir Senkov <ha...@so...>:

> Great work, awesome news!
> 
> Ideally we should get to a point on the roadmap when sample producers
> will be willing to take a particular LS release and approve it for their
> samples. Then we won't need a lot of testers/time and they could get
> maximum features back from LS.

Yes this would be ideal.
Eventually we should keep a list of sample libraries that are 
"certified" to work well with LS (and with which version) and/or if there
are issues.
Anyway I think as soon as the user/developer community of LS reaches critical
mass playback imperfections will be ironed out pretty quickly
(eg differing velocity curves, articulation issues etc).


> What are the minimum features for LS to get to that kind of acceptance?
> VSTi frontend, clusters, etc is all good stuff too, but I think to get
> to that point LS probably just need to implement all the requirements of
> the GIG format just like Christian said. So let's get a detailed TODO
> list published on that, slice it and go for it!

I agree.
Basically first priority is decent GIG playback with a simple load&play GUI
that can work on a windows/mac box too.
Since Rui is using Qt, recompiling on Windows/Mac is just straightforward.
Even if the network layer VSTi/Audiounit frontend is not done yet you could
already use such LS machines professionally. Just put in a decent audio card
and a midi interface and it works.
But of course the networking support with midi and audio over LAN will
lower the total cost of ownership of even more and make it easy to deploy
large sampling clusters without costly audio interfaces, midi interfaces,
cabling etc.


BTW: some sample library producers are still a bit sceptical and would
like to know more about LS and its roadmap.
Probably it would be handy to write a document or some presentation
(powerpoint-like) of what LS is what the current state of art is and
what our short term and long term roadmap looks like.
We don't like to be labeled as hypsters promising tons of features
which will take years to get implemented etc.
Since the source is available we have nothing to hide so we can live without
 marketing speak that's trying to sell hot air.
This is why such a document that will be updated from time to time is useful
for companies that are new to the LS project and want to collaborate with us.
They cannot go through hundreds of mails on mailing lists, posts on forums etc.
So we should summarize the nature, status and goal of project on our website 
so that is is easy to read for non developers too.

> I should be able to contribute at least every other weekend at this
> point.

Excellent ! 
I hope to get back into LS development with full force soon too :-)

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



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

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

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

Hi,
   I already have the MIDI file. I'll be happy to do the testing in the
next day or two.

- Mark

On Tue, 2004-01-27 at 03:59, be...@ga... wrote:
> 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 would be handy if someone that owns GS could try to construct a midi file with
> that trigger that note varying velocities from 0-127 (with pedal down and up).
> And do A/B comparison between GS/LS to see if the velocities and loudness levels
>  correspond.
> 
> cheers,
> Benno
> http://www.linuxsampler.org
> 
> 
> 
> -------------------------------------------------
> This mail sent through http://www.gardena.net
> 
> 
> -------------------------------------------------------
> 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] 32 layer piano demo GIG

[<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 would be handy if someone that owns GS could try to construct a midi file with
that trigger that note varying velocities from 0-127 (with pedal down and up).
And do A/B comparison between GS/LS to see if the velocities and loudness levels
 correspond.

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



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

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

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

Scrive David Olofson <da...@ol...>:


> 
> > I think that doing very much benchmarking before release samples
> > are included is only going to lead to doing it again. In the piano
> > ogg above, what you hear from LS today is only 10-15% of what GSt
> > is doing with the same MIDI file.
> 
> Those 85-90% doesn't add *that* much to the experience, though! ;-)

Keep in mind LS counts stereo voices while GS counts mono voices.
Thus when doing comparisons multiply LS voices by two first (or divide GS voices
by two). I think when release samples and other stuff will be added the
voice difference will not be that big (except if the two samplers do use 
different sustain algorithm (eg sustaining any voice added or only the last
1-2 voices per midi key).

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


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

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

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

On Mon, 2004-01-26 at 08:38, Vladimir Senkov wrote:
> Great work, awesome news!
> 
> Ideally we should get to a point on the roadmap when sample producers
> will be willing to take a particular LS release and approve it for their
> samples. Then we won't need a lot of testers/time and they could get
> maximum features back from LS.
> What are the minimum features for LS to get to that kind of acceptance?
> VSTi frontend, clusters, etc is all good stuff too, but I think to get
> to that point LS probably just need to implement all the requirements of
> the GIG format just like Christian said. So let's get a detailed TODO
> list published on that, slice it and go for it!
> I should be able to contribute at least every other weekend at this
> point.
> 
> Regards,
> Vladimir.
Hi,
   I'll respond just a bit to Benno's email a bit later this evening
when I get home, but in the meantime let me express complete agreement
with you. Let's work on an agreed upon TODO list that has the features
we all think would make the most impact right away.

   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. 

   I know that at least four of the high-volume posters on Northern
Sound live withing a 1 hour drive of where I live, so it's not out of
the question that I could lend some hands on support for them if they
need it, and time permitting.

   I also wonder about helping them with system configuration
(networking, Alsa, etc.) via ssh connections. If we could link up
specific people here with specific people in that community and build a
bridge by making their first trials easier and more successful, then
that would really get these folks to a more successful point more
quickly and, I think, speak well for both Open Source and the Linux
community in general.

   Remember, many will have never seen a Linux box. Many have no idea
that we can fix problems in LA from Northern California like I do on my
74 year old fathers Gentoo box. We're not black box hackers here. I hope
we can bring a few of these folks along.

   Just an idea.

cheers,
Mark

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

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

Great work, awesome news!

Ideally we should get to a point on the roadmap when sample producers
will be willing to take a particular LS release and approve it for their
samples. Then we won't need a lot of testers/time and they could get
maximum features back from LS.
What are the minimum features for LS to get to that kind of acceptance?
VSTi frontend, clusters, etc is all good stuff too, but I think to get
to that point LS probably just need to implement all the requirements of
the GIG format just like Christian said. So let's get a detailed TODO
list published on that, slice it and go for it!
I should be able to contribute at least every other weekend at this
point.

Regards,
Vladimir.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
be...@ga...
Sent: Sunday, January 25, 2004 7:12 PM
To: Linux-Sampler
Subject: [Linuxsampler-devel] LinuxSampler & sample library producers
NAMM report


Hi,
just back from NAMM where I met lots of sample library producers:

I've met people from the following companies:

- Garritan (orchestral strings)
- Post Musical Instruments (pianos like the high quality Bosendorfer
290)
- SAM Project (Horns)
- Bela Media (Vocal samples)
- Vienna Symphonic Library (produces giant orchestral samples taken from
  the Vienna philarmonica orchester etc)
- Sonic Implants
- Dan Dean  (orchestral samples)
- Scarbee (Bass samples)
- Chickensys (produces Translator, a tool that converts between many
sample formats)

I explained the concept of LS, where we currently are, and what's our 
shor tterm and long term roadmap.
To some I showed LS running on the Mediastation (which contains an
Athlon Linux box), to others we showed LS running on the Laptop of Paul
Davis (he was at NAMM too, really a great person :-) ).

The sampler producers are very enthusiastic about LS, because the
technology is open, free and scalable and will be able to integrate
their own stuff they need to provide superior sample playback
experience.

Most of them already donated sample CDs (in GIG format) that we can use
for development purposes (we will share then among selected and trusted
developers that contribute to the codebase and to testing like Mark
does). Most of those that have not yet donated CDs said they intend to.

The feature they are most excited about is networked LS clusters with a
VSTi frontend on Window PC (or Mac using audiounits), because most of
them produce large orchestral libraries which are impossible to run on a
single machine. (the Vienna guys produce libs of 200GB and more !).

So I think the VSTi networking support in LS will be very important for
adoption in large scale enviroments. Christian said we want to make it
to Hollywood studios and I think if we 
do it right this goal will not be too far away :-)

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.

Anyway I must say I did not expect such a positive response. They are
all very friendly people, mostly 1-4 man based companies and you know
it's easier to talk to such companies than to big companies.

A few of the guys expressed ideas about doing a sampler module based on
an embedded PC (like the VIA) running LS and their sample libraries. One
guy said LS could be turned in a high quality organ with dozen of
registers (which would require 20-30voices (RAM voices) per midi key).

I think sample producers are often dependent on softsampler companies
and often their creativity is limited by those commercial softsamplers
because  the commercial softsamplers often do not implement stuff that
is needed only for certain libraries because it does not pay off to
them, plus they try to keep their engines/sample formats as closed as
possible in order to stay ahead of competing companies.


Regarding distributing the sampling CDs, we should decide who will get
access to them. I propose only people that have shown active
contribution to LS. Be it in form of code or in form of testing like
Mark does.

People that comes to mind: Christian, me, Mark, Vladimir, Rui, Tobias E.
others ?

PS: some of the companies said that once LS gets a bit usable they will
try it out and give us feedback if their sound libraries are played back
correctly.

thoughts ?

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





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


-------------------------------------------------------
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...>]

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

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

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

Hi,
just back from NAMM where I met lots of sample library producers:

I've met people from the following companies:

- Garritan (orchestral strings)
- Post Musical Instruments (pianos like the high quality Bosendorfer 290)
- SAM Project (Horns)
- Bela Media (Vocal samples)
- Vienna Symphonic Library (produces giant orchestral samples taken from
  the Vienna philarmonica orchester etc)
- Sonic Implants
- Dan Dean  (orchestral samples)
- Scarbee (Bass samples)
- Chickensys (produces Translator, a tool that converts between many sample formats)

I explained the concept of LS, where we currently are, and what's our 
shor tterm and long term roadmap.
To some I showed LS running on the Mediastation (which contains an Athlon Linux
box), to others we showed LS running on the Laptop of Paul Davis (he was at NAMM
too, really a great person :-) ).

The sampler producers are very enthusiastic about LS, because the technology is
open, free and scalable and will be able to integrate their own stuff they need
to provide superior sample playback experience.

Most of them already donated sample CDs (in GIG format) that we can use
for development purposes (we will share then among selected and trusted
developers that contribute to the codebase and to testing like Mark does).
Most of those that have not yet donated CDs said they intend to.

The feature they are most excited about is networked LS clusters with a VSTi
frontend on Window PC (or Mac using audiounits), because most of them
produce large orchestral libraries which are impossible to run on a single
machine. (the Vienna guys produce libs of 200GB and more !).

So I think the VSTi networking support in LS will be very important
for adoption in large scale enviroments.
Christian said we want to make it to Hollywood studios and I think if we 
do it right this goal will not be too far away :-)

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.

Anyway I must say I did not expect such a positive response.
They are all very friendly people, mostly 1-4 man based companies and you
know it's easier to talk to such companies than to big companies.

A few of the guys expressed ideas about doing a sampler module based on
an embedded PC (like the VIA) running LS and their sample libraries.
One guy said LS could be turned in a high quality organ with dozen
of registers (which would require 20-30voices (RAM voices) per midi key).

I think sample producers are often dependent on softsampler companies and
often their creativity is limited by those commercial softsamplers because
 the commercial softsamplers often do not implement stuff that is needed
only for certain libraries because it does not pay off to them, plus
they try to keep their engines/sample formats as closed as possible
in order to stay ahead of competing companies.


Regarding distributing the sampling CDs, we should decide who will get
 access to them.
I propose only people that have shown active contribution to LS.
Be it in form of code or in form of testing like Mark does.

People that comes to mind: Christian, me, Mark, Vladimir, Rui, Tobias E.
others ?

PS: some of the companies said that once LS gets a bit usable they will
try it out and give us feedback if their sound libraries are played back
 correctly.

thoughts ?

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





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

[Linuxsampler-devel] GSt announcements of potential interest

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

Of potential interest to LS folks:

New GSt 3.0 brochure

http://www.truespec.com/downloads/pdf/gigastudio/GigaStudio3.pdf

VST/RTAS wrapper - $99

Now Pro Tools users can take advantage of VST meaning the decision here
to do a VST device to talk to LS will work with Pro Tools also.

http://www.fxpansion.com/product-rtasadapter-main.php

Re: [Linuxsampler-devel] ADSDR 6th try

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

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

Re: [Linuxsampler-devel] ADSDR 6th try

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

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.

Mark Knecht wrote:

>Vladimir,
>   Thanks. This seems to have patched correctly using
>
>patch -p1 <../adsdr5
>
>Is there anything specific you want me to look for? I suppose I'll have
>to try out Christian's Jack support also.
>
>Thanks,
>Mark
>
>On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote:
>  
>
>>Mark,
>>
>>Christian has just checked things into cvs and now eg code has changed a 
>>little.
>>I've merged the changes and here is a patch against the latest CVS.
>>
>>Regards,
>>Vladimir.
>>
>>Mark Knecht wrote:
>>
>>    
>>
>>>On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote:
>>> 
>>>
>>>      
>>>
>>>>No, no chance of me not floodding this list today :(
>>>>Left some debug in there . . .
>>>>So here you go again.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>I must not be doing this correctly. This is against Christian's CVS
>>>commit from today.
>>>
>>>bash-2.05b$ pwd
>>>/home/mark/data/LinuxSampler
>>>bash-2.05b$ cd linuxsampler
>>>bash-2.05b$ ls
>>>AUTHORS   INSTALL       README          config.guess  configure.in           linuxsampler.kdevelop.pcs  missing
>>>COPYING   Makefile.am   acconfig.h      config.h.in   depcomp                linuxsampler.kdevses       mkinstalldirs
>>>CVS       Makefile.cvs  aclocal.m4      config.sub    install-sh             ltconfig                   src
>>>Doxyfile  Makefile.in   autom4te.cache  configure     linuxsampler.kdevelop  ltmain.sh                  templates
>>>
>>>
>>>bash-2.05b$ patch -p1 <../adsdr4 
>>>patching file src/eg_vca.cpp
>>>Hunk #2 FAILED at 97.
>>>1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej
>>>patching file src/eg_vca.h
>>>Hunk #1 FAILED at 40.
>>>1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej
>>>patching file src/voice.cpp
>>>bash-2.05b$ 
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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
>
>  
>

Re: [Linuxsampler-devel] ADSDR 5th try

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

Mark,

If you could try playing using different gigs. I only have a few and i'm 
sure there are going to be problems with some combinations of parameters 
. . .
You should notice gigs without infinite sustain play differently now 
also try samples with post attack hold if you have those.

Regards,
Vladimir.

PS: Jack support is great i'll play around with it as well.

Mark Knecht wrote:

>Vladimir,
>   Thanks. This seems to have patched correctly using
>
>patch -p1 <../adsdr5
>
>Is there anything specific you want me to look for? I suppose I'll have
>to try out Christian's Jack support also.
>
>Thanks,
>Mark
>
>On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote:
>  
>
>>Mark,
>>
>>Christian has just checked things into cvs and now eg code has changed a 
>>little.
>>I've merged the changes and here is a patch against the latest CVS.
>>
>>Regards,
>>Vladimir.
>>
>>Mark Knecht wrote:
>>
>>    
>>
>>>On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote:
>>> 
>>>
>>>      
>>>
>>>>No, no chance of me not floodding this list today :(
>>>>Left some debug in there . . .
>>>>So here you go again.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>I must not be doing this correctly. This is against Christian's CVS
>>>commit from today.
>>>
>>>bash-2.05b$ pwd
>>>/home/mark/data/LinuxSampler
>>>bash-2.05b$ cd linuxsampler
>>>bash-2.05b$ ls
>>>AUTHORS   INSTALL       README          config.guess  configure.in           linuxsampler.kdevelop.pcs  missing
>>>COPYING   Makefile.am   acconfig.h      config.h.in   depcomp                linuxsampler.kdevses       mkinstalldirs
>>>CVS       Makefile.cvs  aclocal.m4      config.sub    install-sh             ltconfig                   src
>>>Doxyfile  Makefile.in   autom4te.cache  configure     linuxsampler.kdevelop  ltmain.sh                  templates
>>>
>>>
>>>bash-2.05b$ patch -p1 <../adsdr4 
>>>patching file src/eg_vca.cpp
>>>Hunk #2 FAILED at 97.
>>>1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej
>>>patching file src/eg_vca.h
>>>Hunk #1 FAILED at 40.
>>>1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej
>>>patching file src/voice.cpp
>>>bash-2.05b$ 
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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
>
>  
>

Re: [Linuxsampler-devel] ADSDR 5th try

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

Vladimir,
   Thanks. This seems to have patched correctly using

patch -p1 <../adsdr5

Is there anything specific you want me to look for? I suppose I'll have
to try out Christian's Jack support also.

Thanks,
Mark

On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote:
> Mark,
> 
> Christian has just checked things into cvs and now eg code has changed a 
> little.
> I've merged the changes and here is a patch against the latest CVS.
> 
> Regards,
> Vladimir.
> 
> Mark Knecht wrote:
> 
> >On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote:
> >  
> >
> >>No, no chance of me not floodding this list today :(
> >>Left some debug in there . . .
> >>So here you go again.
> >>
> >>    
> >>
> >
> >I must not be doing this correctly. This is against Christian's CVS
> >commit from today.
> >
> >bash-2.05b$ pwd
> >/home/mark/data/LinuxSampler
> >bash-2.05b$ cd linuxsampler
> >bash-2.05b$ ls
> >AUTHORS   INSTALL       README          config.guess  configure.in           linuxsampler.kdevelop.pcs  missing
> >COPYING   Makefile.am   acconfig.h      config.h.in   depcomp                linuxsampler.kdevses       mkinstalldirs
> >CVS       Makefile.cvs  aclocal.m4      config.sub    install-sh             ltconfig                   src
> >Doxyfile  Makefile.in   autom4te.cache  configure     linuxsampler.kdevelop  ltmain.sh                  templates
> >
> >
> >bash-2.05b$ patch -p1 <../adsdr4 
> >patching file src/eg_vca.cpp
> >Hunk #2 FAILED at 97.
> >1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej
> >patching file src/eg_vca.h
> >Hunk #1 FAILED at 40.
> >1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej
> >patching file src/voice.cpp
> >bash-2.05b$ 
> >
> >
> >
> >-------------------------------------------------------
> >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 5th try

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

Mark,

Christian has just checked things into cvs and now eg code has changed a 
little.
I've merged the changes and here is a patch against the latest CVS.

Regards,
Vladimir.

Mark Knecht wrote:

>On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote:
>  
>
>>No, no chance of me not floodding this list today :(
>>Left some debug in there . . .
>>So here you go again.
>>
>>    
>>
>
>I must not be doing this correctly. This is against Christian's CVS
>commit from today.
>
>bash-2.05b$ pwd
>/home/mark/data/LinuxSampler
>bash-2.05b$ cd linuxsampler
>bash-2.05b$ ls
>AUTHORS   INSTALL       README          config.guess  configure.in           linuxsampler.kdevelop.pcs  missing
>COPYING   Makefile.am   acconfig.h      config.h.in   depcomp                linuxsampler.kdevses       mkinstalldirs
>CVS       Makefile.cvs  aclocal.m4      config.sub    install-sh             ltconfig                   src
>Doxyfile  Makefile.in   autom4te.cache  configure     linuxsampler.kdevelop  ltmain.sh                  templates
>
>
>bash-2.05b$ patch -p1 <../adsdr4 
>patching file src/eg_vca.cpp
>Hunk #2 FAILED at 97.
>1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej
>patching file src/eg_vca.h
>Hunk #1 FAILED at 40.
>1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej
>patching file src/voice.cpp
>bash-2.05b$ 
>
>
>
>-------------------------------------------------------
>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 4th try

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

On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote:
> No, no chance of me not floodding this list today :(
> Left some debug in there . . .
> So here you go again.
> 

I must not be doing this correctly. This is against Christian's CVS
commit from today.

bash-2.05b$ pwd
/home/mark/data/LinuxSampler
bash-2.05b$ cd linuxsampler
bash-2.05b$ ls
AUTHORS   INSTALL       README          config.guess  configure.in           linuxsampler.kdevelop.pcs  missing
COPYING   Makefile.am   acconfig.h      config.h.in   depcomp                linuxsampler.kdevses       mkinstalldirs
CVS       Makefile.cvs  aclocal.m4      config.sub    install-sh             ltconfig                   src
Doxyfile  Makefile.in   autom4te.cache  configure     linuxsampler.kdevelop  ltmain.sh                  templates


bash-2.05b$ patch -p1 <../adsdr4 
patching file src/eg_vca.cpp
Hunk #2 FAILED at 97.
1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej
patching file src/eg_vca.h
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej
patching file src/voice.cpp
bash-2.05b$ 

Re: [Linuxsampler-devel] Latest CVS commit

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

Es geschah am Sonntag, 18. Januar 2004 21:09 als Vladimir Senkov schrieb:
> Cool.
> I've pulled down the latest LS from cvs but it looks the same as before
> though. is there any replication involved?

Now it is. Just a bit patience! ;)

[Linuxsampler-devel] Lates CVS commit

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

Changes:

	- added JACK support; you'll need to have libjack headers and pkg-config
	  installed in order to be able to compile LinuxSampler with JACK support.
	  If you have not, it will compile with Alsa support only. If compiled with
	  JACK support, LinuxSampler will first try to connect to the JACK server.
	  If this fails it will automatically fallback to Alsa output.
	- applied the patch from Vladimir which fixes the mentioned small bug with
	  hanging notes in conjunction with the sustain pedal

CU
Christian

Re: [Linuxsampler-devel] ADSDR 4th try

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

No, no chance of me not floodding this list today :(
Left some debug in there . . .
So here you go again.

Vladimir Senkov wrote:

> Everybody,
>
> Those two previous patches had a nasty bug, so here is another one. 
> please disregard the other two.
> Sorry for too many messages. It's weekend. you'll probably not hear 
> from me on weekdays :)
>
> Christian,
> Does Release coefficient have to take sustain level into consideration?
> It seems that it is not really necessary, but i'm not sure.
>
> Regards,
> Vladimir.