Re: [Linuxsampler-devel] Just a report

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

On Sat, 1 Jan 2005 17:15:52 +0100, Christian Schoenebeck
<sch...@so...> wrote:
> Happy new year everybody! :)

And to you!

> 
> Wow, Vladimir was really assiduous and that even on new years eve!
> 
> Es geschah am Samstag 01 Januar 2005 03:12 als Mark Knecht schrieb:
> > > Memory stats could be looked at by tools like "top"
> >
> > Yes, but that doesn't show what each gig file or each sample, etc., is
> 
> We could easily collect the amount of cached sample data in the
> InstrumentResourceManager. But I think we'll better postpone that for the
> time after the first release.

If the info was going to be part of the app then I agree. I'm
wondering if it is possible to write some small support app, just
console based, that could query LS (or Linux itself) for LS memory
usage?

> 
> > When Christian and I discussed this problem, probably about a year
> > ago, it was my understanding he thought that the compression
> > algorythmn might be different than other files and hence this causes
> > the problem. I don['t think we ever tested that idea fully.
> 
> I thought you only had problems with LS's interpretation of articulation
> informations. If there's a problem wirh the decompression algorithm you would
> hear noise or something. Or did I get you wrong?

Sorry. I do hear noise with these gig files. Underneath the noise I
can hear the note, but badly distorted. It's a bass guitar, but I hear
mostly high frequencies only and covered up with noise.

> 
> Mark, you mentioned there was still a problem with your Scarbee J-Fingered
> Bass gig. What exactly was the problem?

As stated above. I can record the gig from both apps and send you
mp3's if it will help.

Can gigdump extract certain samples from the gig file? Maybe I could
send a single sample and you could figure it out from there. Or tell
me how I might investigate this more here and I'll give it a try.

> 
> Vladimir, you are right regarding the disk thread. Of course it makes sense to
> share one single disk thread between all instances of the same sampler engine
> type. I also planned to change that long ago, but did not do it yet due to
> priorities. The engine concept should also be changed a bit, but I propose to
> do these things after the upcoming release.
> 

WRT to the upcoming release I think you guys are really very close. In
my mind there are just a couple of things that must happen either
before or soon after release:

1) More a qsampler issue possibly but based on yesterday's work I'm
having lots of problems saving and restoring setups. I store *.lscp
file and then it won't restore. LS reports that it cannot set up
channels or parameters. I would encourage the group to take a close
look at this and make sure it won't look flaky to new users. (I expect
almost all users to end up using qsampler.)

2) The Scarbee issue as above. It's a pretty popular set of libraries
used by a lot of folks. If you do release without it fixed then we
need to state it doesn't work up front and say when we'll fix it.
(Basic errata issue)

3) More structural, but LS needs to support more than a stereo output.
I record LS output into Ardour or Pro Tools and I need piano, drums,
bass, all on separate stereo channels. Folks doing orchestral are used
to recording maybe 8-10 separate groups of sounds for mixing later. LS
doesn't seem to support anything like this today. We need some of the
features in the DSP station portion of GSt, where we route LS channels
to certain mixer elements and then attach certain mixer  elements to
certain hardware outputs. (Or alsa_pcm channels.)

Those are my thoughts for now. I've just finished build Vladimir's
latest updates so I'll do some more testing today and see how it goes.
My main goal right now is to do some 30-100 voice recordings using Pro
Tools and LS only to see how well it holds up. It broke yesterday so I
hope Vladimir's work helps.

Cheers,
Mark