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

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

> On Mon, Jan 20, 2003 at 09:42:04 -0800, Mark Knecht wrote:
> > Steve,
> >    I completely understand.
> >
> >    Question - the linuxsampler-gcc code I got from your server
> compiles with
> > no options in the ./configure stage, but fails when I try the
> --enable-jack
> > option. Does Jack support work for this code yet? Do I need to
> enable other
> > options to enable jack support?
>
> I dont know, you'd have to ask Juan, its his code. I've a feeling that the
> jack code is based on an old version of the API.
>
> - Steve

I just wondered if you had tried to do it. ;-)

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

On Mon, Jan 20, 2003 at 09:42:04 -0800, Mark Knecht wrote:
> Steve,
>    I completely understand.
> 
>    Question - the linuxsampler-gcc code I got from your server compiles with
> no options in the ./configure stage, but fails when I try the --enable-jack
> option. Does Jack support work for this code yet? Do I need to enable other
> options to enable jack support?

I dont know, you'd have to ask Juan, its his code. I've a feeling that the
jack code is based on an old version of the API.

- Steve 

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

Steve,
   I completely understand.

   Question - the linuxsampler-gcc code I got from your server compiles with
no options in the ./configure stage, but fails when I try the --enable-jack
option. Does Jack support work for this code yet? Do I need to enable other
options to enable jack support?

Cheers,
Mark

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> Steve Harris
> Sent: Monday, January 20, 2003 9:21 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Mon, Jan 20, 2003 at 05:09:19 +0100, David Olofson wrote:
> > XAP is a plugin API, so it doesn't really deal with sampling or any
> > other form of synthesis directly. Linuxsampler would be very useful
> > as a XAP plugin, but that's really more of an API selection matter
> > from Linuxsampler's POV. That is, we still need something to turn
> > into a XAP plugin. :-)
>
> I think that the plans we have for linuxsampler make it a better inprocess
> jack app than a XAP plugin. Several of us have other things that are more
> urgent, but we will resume work in a few* weeks.
>
> I have a couple of conferences and a gig to prepare for urgently and Benno
> and Juan have a lot of work on.
>
> * Where few is > 1 ;)
>
> - Steve
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

Hi all,
sorry for this quiet phase, but the work at the ISP I work for
took a month longer than expected.
Before the end of the month it will be done thus I will finally
 be able to get back on linuxsampler. (hopefully I'll not be regarded
 as the vaporware man because of these delays ;-) )

Anyway in december I wrote some benchmark code and enveloping and
 event schemes for basic building blocks (the sampler engine).
I have not implemented this stuff in code but I have some stuff
written on paper.
Now I see this XAP stuff from David O., it looks very cool but due
of my scarce spare time during the last weeks I was unable to
 read all the gigabytes of text that David and other produced.

Perhaps it would be beneficial for all us to implement LinuxSampler
 as a XAP plugin ? who knows ? 
The fact that LinuxSampler's goal is to being able to user compiler
techniques (you "draw" the signal graph on the screen , compile the
result into C code and then run it through loading the .so module),
 means that the API needs to be flexible and/or extensible so I
 have currently no idea if it would be a good idea to build LinuxSampler
 on XAP internally or treat it as a black box and export only the
 audio-out channels, the MIDI-ins plus some internal controls.

I think it will be a good idea to keep the thoughts of XAP and
 LinuxSampler guys in sync in order to optimize both the API and
 the sampler engine.

In a week or so I will discuss and ask for comments about my ideas of
implementing the modular sample playback engine that uses compilation.
One of the most interesting topics will be how we implement efficient
 event passing between the sampler's modules (eg two envelop generators
that output to an adder module which in turn drives the sampler's pitch
 or volume.
Being a bit of a nitpicker, I'd like to achieve sample accurate
or near sample accurate event timing, allow dense streams of events
(eg up to 1/4 - 1/8 samplerate) without too much performance penalty
while retaining modularity and flexible event routing).
It's not an easy task to solve, but my preliminary brainstorming
 suggests me that it is possible to retain high accuracy with only
 a few small tradeoffs.
David is a quite good "event-hacker" so I hope that he gives us the
right advices in order to avoid design mistakes.

Immagine the handyness of loading an akai.so, module and start playing
AKAI libraries with the speed of a hardcoded engine.
The same can be said of GIG libraries.
Fortunately the disk playback was solved a few years ago so what's missing
 is mainly some good event/modulation system, sample loading libriaries
(swami etc) and a GUI (the proposal was
to decouple the GUI from the engine using a TCP socket so that you can
build headless "sampler farms" that can be controlled remotely from an
 arbitrary machine (even a TCP/IP equipped PDA :-))

I know many would like quick results fast (I would like them too), but
 unfortunately a good audio engine takes time to design and we have only
 few complex open source audio projects where we can learn from.

I think the biggest near term challenge is to get the basic sampler
(with recompiler) and even system up and running.
From this point it will be easy to parallelize work so that people
can start working on sample libraries, GUIs etc, testing and improving 
the accuracy of reproduction of sample libraries etc. (filters, envelopes, 
modulators, keyzones etc)


cheers,
Benno





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

> On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> > Hey Mark,
> >                 I've been on this list for a few months as well and
> > noticed it's kind of died down.  Not sure what's up with that - it
> > was very active around November, iirc.  There has been some
> > discussion about Swami, but I think the real hope for sampling
> > under Linux might be XAP (discussed extensively on
> > linux-audio-dev.)
> 
> Well, I'm not really involved with Linuxsampler, but I'm certainly 
> responsible for most of the bandwidth in the XAP discussion. ;-)
> 
> XAP is a plugin API, so it doesn't really deal with sampling or any 
> other form of synthesis directly. Linuxsampler would be very useful 
> as a XAP plugin, but that's really more of an API selection matter 
> from Linuxsampler's POV. That is, we still need something to turn 
> into a XAP plugin. :-)
> 
> 
> //David Olofson - Programmer, Composer, Open Source Advocate
> 


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

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

On Mon, Jan 20, 2003 at 05:09:19 +0100, David Olofson wrote:
> XAP is a plugin API, so it doesn't really deal with sampling or any 
> other form of synthesis directly. Linuxsampler would be very useful 
> as a XAP plugin, but that's really more of an API selection matter 
> from Linuxsampler's POV. That is, we still need something to turn 
> into a XAP plugin. :-)

I think that the plans we have for linuxsampler make it a better inprocess
jack app than a XAP plugin. Several of us have other things that are more
urgent, but we will resume work in a few* weeks.

I have a couple of conferences and a gig to prepare for urgently and Benno
and Juan have a lot of work on.

* Where few is > 1 ;)

- Steve

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

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

David & David,
   Was that the name of a band in the late 80's maybe? I must go look.

   Well, if it served no other purpose, at least my 1st posted created a
little bit of traffic on the list, right? ;-)

   From my conversation with Benno, and then just watching the discussions
on Linux-Audio-Dev, I can tell that there are a few things going on. If it's
too early, it's too early, but I wanted to simply join up and express my
interest. I'm not a software guy, so there isn't much I can do to help in
that area, but I have numerous computers and lots of interest, so when
things are ready for people like me, I'm here.

   I presume that there will be interest in supporting pre-existing
libraries. I certainly have a great desire to use the ones I own. (I'd like
a good prepared piano also!) ;-) Has any work happened to be able to open a
GSt library and get data out of it? If so, I could do testing at that level
even if the files cannot really be used right now.

   As always, I probably have too many ideas, but personally I'd really like
to see a sample player somewhat like Battery for Linux. I think that it's a
much more simple interface, requires far fewer system resources to work
well, could use Wave files easily. I just think overall it would get a lot
of use up front. The existing sample players, like iiwusynth and timidity
are not, IMO, really very good for dealing with drum sets.

   Has there been any discussion of doing something like that?

   I mentioned this to the individual that did the little SimSam player, but
haven't heard back.

   Anyway, I'll just hand out and see what happens.

   I haven't paid too much attention to XAP as I think it's too much below
the hood for someone like me. I'm glad to see that you are thinking of
samplers with it. I can tell folks are interested.

Cheers,
Mark

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Monday, January 20, 2003 8:09 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> > Hey Mark,
> >                 I've been on this list for a few months as well and
> > noticed it's kind of died down.  Not sure what's up with that - it
> > was very active around November, iirc.  There has been some
> > discussion about Swami, but I think the real hope for sampling
> > under Linux might be XAP (discussed extensively on
> > linux-audio-dev.)
>
> Well, I'm not really involved with Linuxsampler, but I'm certainly
> responsible for most of the bandwidth in the XAP discussion. ;-)
>
> XAP is a plugin API, so it doesn't really deal with sampling or any
> other form of synthesis directly. Linuxsampler would be very useful
> as a XAP plugin, but that's really more of an API selection matter
> from Linuxsampler's POV. That is, we still need something to turn
> into a XAP plugin. :-)
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .- The Return of Audiality! --------------------------------.
> | Free/Open Source Audio Engine for use in Games or Studio. |
> | RT and off-line synth. Scripting. Sample accurate timing. |
> `---------------------------> http://olofson.net/audiality -'
>    --- http://olofson.net --- http://www.reologica.se ---
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> Hey Mark,
>                 I've been on this list for a few months as well and
> noticed it's kind of died down.  Not sure what's up with that - it
> was very active around November, iirc.  There has been some
> discussion about Swami, but I think the real hope for sampling
> under Linux might be XAP (discussed extensively on
> linux-audio-dev.)

Well, I'm not really involved with Linuxsampler, but I'm certainly=20
responsible for most of the bandwidth in the XAP discussion. ;-)

XAP is a plugin API, so it doesn't really deal with sampling or any=20
other form of synthesis directly. Linuxsampler would be very useful=20
as a XAP plugin, but that's really more of an API selection matter=20
from Linuxsampler's POV. That is, we still need something to turn=20
into a XAP plugin. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David G. M. <dg...@pi...>]

Hey Mark,
                I've been on this list for a few months as well and 
noticed it's kind of died down.  Not sure what's up with that - it was 
very active around November, iirc.  There has been some discussion about 
Swami, but I think the real hope for sampling under Linux might be XAP 
(discussed extensively on linux-audio-dev.)  I also use Gigasampler a 
bit and seeing as I'd like to dump Windoze altogether I'm hoping for a 
way to use my libraries in Linux (like my really nifty Akai-format 
prepared piano CD...)
-dgm

Mark Knecht wrote:

>Hello all,
>   A few weeks ago Benno and I were talking about something else (hardware)
>and he found out I'm a GigaStudio user. He suggested I check out the
>LinuxSampler project. He did tell me it wasn't ready for testers, however,
>if I can lend a hand early on with working on feature sets or compatibility
>with existing libraries, I'd certainly be happy to do so. I have a couple
>thousand dollars worth of GigaStudio libraries, as well as some Akai samples
>and what not. Would love to see them go under Linux.
>
>   I see this list has been quiet for about a month. That's a bit sad, but I
>understand that many other things are going on. 
>
>   I did find that Steve had put a copy of the code on his site. I
>downloaded and built it on RH 7.3. It runs, or at least it starts. I don't
>know what to do with it!!
>
>   If the action is actually elsewhere, like on Swami, then point me in the
>right direction. I'm definitely interested in seeing some sort of
>GSt/Halion/Kontact software up and running in Open Source. That would be
>great.
>
>Cheers,
>Mark
>  
>

[Linuxsampler-devel] Hi - Very quiet list - my first post

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

Hello all,
   A few weeks ago Benno and I were talking about something else (hardware)
and he found out I'm a GigaStudio user. He suggested I check out the
LinuxSampler project. He did tell me it wasn't ready for testers, however,
if I can lend a hand early on with working on feature sets or compatibility
with existing libraries, I'd certainly be happy to do so. I have a couple
thousand dollars worth of GigaStudio libraries, as well as some Akai samples
and what not. Would love to see them go under Linux.

   I see this list has been quiet for about a month. That's a bit sad, but I
understand that many other things are going on. 

   I did find that Steve had put a copy of the code on his site. I
downloaded and built it on RH 7.3. It runs, or at least it starts. I don't
know what to do with it!!

   If the action is actually elsewhere, like on Swami, then point me in the
right direction. I'm definitely interested in seeing some sort of
GSt/Halion/Kontact software up and running in Open Source. That would be
great.

Cheers,
Mark

[Linuxsampler-devel] Re: Linuxsampler-devel digest, Vol 1 #32 - 2 msgs

[Paul K. <pau...@ma...>]

Christian Schoenebeck <chr...@ep...> wrote:
>
> Has anybody already thought about incorporating formant manipulation into
the
> engine? That way the user would be able to e.g. pitch a sample without
> sounding synthetic. That works at least for some semi tones.
>
> And what about time stretching?


It was mentioned a long time ago (I think on linux-audio-dev) as something
that
would be nice to have, but it's probably easiest to implement for samples that
are completely in memory.

For a lot of samples, particularly drum loops where you are only going to use
one or a few shifted versions, it's more efficient to render the pitch shifted
version(s) to memory or disk rather than calculate them live.  It then becomes
a job for the interface rather than for the real-time engine.

Interactive pitch/formant shifting (like the Roland VariPhrase and Native
Instruments Kontakt) probably needs to have an intermediate "analysis" file
created, which is what gets played back.  One way to handle this would be
if the engine could use custom "renderers" for particular file types.

The technology for pitch and formant shifting is known (usually LPC analysis,
inverse filtering to flatten the spectrum, pitch shifting by crossfading
between buffers (pitch synchronously if the audio is monophonic) then
filtering
to re-apply the spectrume shape, or a shifted version of it) but is just a lot
of work for someone to get it sounding good.  Probably what is important at
this
stage is to make sure the engine can cope with this sort of thing in the
future.


Paul.

_____________________________

  m a x i m | digital audio

    http://mda-vst.com
_____________________________

[Linuxsampler-devel] Formant manipulation

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

Has anybody already thought about incorporating formant manipulation into the 
engine? That way the user would be able to e.g. pitch a sample without 
sounding synthetic. That works at least for some semi tones.

And what about time stretching?

Regards, 
Christian

Re: [Linuxsampler-devel] evo code

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

Es geschah am Mittwoch, 11. Dezember 2002 23:08 als Benno Senoner schrieb:
> > > This check can be moved within the disk thread which accesses the
> > > buffer with a much lower frequency and where it is easy to figure out
> > > when the last read reached the ring buffer end position.
> >
> > I'm not sure what you're getting at. Do you mean that it's more likely
> > that read/write access to the buffer won't interfere/overlap, because the
> > audio thread reads faster than the disk buffer can fill up the space, due
> > to the higher priority of the audio thread?
>
> no, the disk thread "always writes faster than the audio thread reads",
> or in short: there will be always some data in the ring buffer as long
> as the disk is not overloaded (if that happens we must lower the max #
> of voices or user more powerful hardware ... it is not our fault).

Oh, I expressed myself wrong. Anyway, I think I got the idea.

Thanks!

Re: [Linuxsampler-devel] Anything going on?

[Josh G. <jg...@us...>]

On Thu, 2002-12-12 at 03:21, Antti Boman wrote:
> Josh Green wrote:
> > Well, I'm still ploding along on Swami development. New devel branch
> > is.. well developing :) libInstPatch has some more testing under its
> > belt and a Python interface is beginning to form. I'm starting to
> > re-work the GUI side of things to make it more pluggable in anticipation
> > of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
> > SF1). Much of this has still not been committed to CVS, although I would
> > be quick to commit it if I knew someone was interested (hint hint).
> 
> No-one is. No, seriously, I'm interested :) And ready to test and help.
> 
> -a

Cool :) There is quite a lot of things to do with Swami, so if you
really are interested, join the swami-devel mailing list (nothing
happening there at the moment, except for my status reports from time to
time). The development branch of Swami/libInstPatch has not quite
reached the stage where testing is really useful (still some things to
implement). If you are good with GUIs, I could use some ideas and brain
storming of how the user interface could be re-designed. The underlying
architecture is very object oriented (in a good way) but the GUI still
looks like the old Smurf SoundFont Editor (which is a mock up of a
screen shot I had of Vienna).

I want the new GUI to have a flexible layout (using the Gtk(H/V)Paned
widgets for now until a more flexible one is written) where the type of
UI element can be set (patch tree, patch properties, effect controls,
sample waveform loop control, GUI envelopes, etc) and these elements can
be docked or undocked from different windows. There could then be layout
presets (such as a "Classic" one that would resemble the current
interface). I'm just now re-writing the object state save/restore system
which is going to be XML based using libxml2 which will help a lot with
making the user interface more object oriented (and being able to
actually store this for later use).

Also much needs to be done in the area of adding API to the different UI
objects that plugins can take advantage of. A plugin may for instance
want to add its own operations to the right-click menu on the patch tree
object, add its own configuration UI to the preferences dialog, etc.

Anyways, additional discussion should probably occur on the swami-devel
list. One need not be an expert to help out and there is a lot of other
things besides GUI work that could use some help :) Cheers.
	Josh Green

Swami website: http://swami.sourceforge.net
Swami mailing lists: http://sourceforge.net/mail/?group_id=47510

Re: [Linuxsampler-devel] Anything going on?

[David O. <da...@ol...>]

On Thursday 12 December 2002 14.17, Benno Senoner wrote:
> Antii, no problem regarding your skills in a good product, the GUI
> is as important as the engine thus your help will be very precious.
>
> PS: I'm CCing David Olofson which has revived Audiality (a
> sampler/synth engine that ranges from games to building high
> quality soft synths/samplers ... see his posts on LAD.
>
> I hope David joins our mailing list since he is very knowledgable
> when it comes to efficient real time code, time stamping of events
> etc. At time David and I have had really cool (private) discussions
> about event systems, sample accurate time stamps for plugins /
> engines etc, David, I see you have now a bit more time to dedicate
> to linux audio things.

Well, yes - I've put Kobo Deluxe, glSDL and that on hold for now, and=20
most of the time has been spent on Audiality lately. (Except for the=20
last few days, which I've spent mostly discussing and working on XAP;=20
our new instrument plugin API.)

Oh, Audiality and XAP both have (rudimentary, but still) pages on my=20
site:
=09http://olofson.net=09(try the naigation bar :-)


> Do you intend to join our quest to provide
> this highly universal sampler engine that could be used for many
> apps ranging from games to high quality midi software sound modules
> ?
> I mean, from your web page it seems that both audiatily and
> linuxsampler  want to achieve similar goals. You mentioned the
> willing of implement disk streaming too, so why not unite the two
> things ? In my opinion it would make sense.

I don't know yet. It would obviously seem like we have *lots* of=20
common goals, and also more than a few design choices in common.

There are basically three things we need to agree on:

=09* Language
=09=09I strongly prefer C, mostly for portability reasons,
=09=09but also since I don't think the complexity of the
=09=09engine motivates the use of C++. (And mind you; I
=09=09have a scripting engine in there! ;-)

=09* Scalability
=09=09Audiality runs rather well on very low end PCs. Due
=09=09to the extremely space efficient script based sounds,
=09=09it's possibly to fit rather high quality music in
=09=09a few kB - on par with IXS. These are things I would
=09=09like to maintain and explore further. (Although they
=09=09may not be my top priorities right now.)

=09* License
=09=09LGPL is the only license that makes sense for
=09=09Audiality. (Which means that I'll have to "clean"
=09=09the code if I can't get in touch with Masanao Izumo.)
=09=09The GPL is too restrictive, since it does not allow
=09=09the use of Audiality as the audio/music engine in
=09=09proprietary games and multimedia productions.


> I think is is a good thing if you people come up with
> solutions/proposals for implementing a sampler engine, but in the
> long run it would be wise to join our forces and work on highly
> reusable modular components like samplelibrary reading libs, sample
> rendering engines, patch editors etc.

Yes indeed. If XAP turns out right, there's a good chance of=20
Audiality being split up into a "plugin kit", since it's already=20
working in similar ways to a XAP plugin net internally. (In fact, the=20
event system in my XAP proposal is just a slightly generalized=20
version of the Audiality event system - which in turn, was derived=20
from the MAIA code.)

I think we might have a rather nice pilot project for XAP here. This=20
design needs serious review and testing before finalizing, and using=20
it to modularize Audiality as well as a framework for Linuxsampler=20
should probably force most issues to surface. These two projects=20
include off-line rendering, direct-from-disk playback, advanced real=20
time control (soon scripting in Audiality) and real time processing.=20
Add a sequencer with some editing operations, we have a "test suite"=20
the covers most plugin API features we can think of - as well as a=20
pretty cool toolkit! :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
=2E- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Benno Senoner wrote:
> Antii, no problem regarding your skills in a good product, the GUI is
> as important as the engine thus your help will be very precious. 

Thanks. I'll follow the discussion on the list and try to gather the 
information what's needed and how it should be done. UI-wise, at the moment.

-a

Re: [Linuxsampler-devel] Anything going on?

[Phil K. <phi...@el...>]

Thanks Steve,

It compiles and runs fine.

I'll have a better play and dig through the code later.

Cheers

Phil

On Thu, 2002-12-12 at 12:11, Steve Harris wrote:
> OK, its on
> http://www.ecs.soton.ac.uk/~swh/linuxsampler-2002-12-12.tar.gz
> 
> I added some patches to make it compile unser gcc3, but it should be OK on
> older compilers still.
> 
> - Steve
> 
> On Thu, Dec 12, 2002 at 10:56:43 +0000, Phil Kerr wrote:
> > Can someone pop it on a server somewhere so I can have a play, or if
> > it's not too big, < 500k, email me a copy.
> > 
> > On Thu, 2002-12-12 at 10:57, Steve Harris wrote:
> > > On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> > > > The cvs is quite outdated..
> > > > I cant commit it seems (either i dont underst very well how sourceforge works,
> > > > or my account is wrong, or i forgot my password :), so i've sent
> > > > the latest tarball to benno and steve...
> > > > Benno seems to be quite busy this week, but i hope
> > > > he gets to review/upoaded the latest tarball...
> > > 
> > > I built it OK, but I had some alsa seq realted problems and so couldn't
> > > try it. I'l give it another go when I have a chance.
> > > 
> > > - Steve 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > With Great Power, Comes Great Responsibility 
> > > Learn to use your power at OSDN's High Performance Computing Channel
> > > http://hpc.devchannel.org/
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > 
> 
> -- 
> Stephen Harris                    07970 557047
> AKT, IAM Research Group          023 8059 2831
> University of Southampton, UK
> sw...@ec...     http://www.aktors.org/           
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Anything going on?

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

Antii, no problem regarding your skills in a good product, the GUI is
as important as the engine thus your help will be very precious. 

PS: I'm CCing David Olofson which has revived Audiality (a sampler/synth
engine that ranges from games to building high quality soft
synths/samplers ... see his posts on LAD.

I hope David joins our mailing list since he is very knowledgable when
it comes to efficient real time code, time stamping of events etc.
At time David and I have had really cool (private) discussions about
event systems, sample accurate time stamps for plugins / engines etc, 
David, I see you have now a bit more time to dedicate to linux audio
things. Do you intend to join our quest to provide this highly universal
 sampler engine that could be used for many apps ranging from games to
 high quality midi software sound modules ?
I mean, from your web page it seems that both audiatily and
linuxsampler  want to achieve similar goals. You mentioned the willing
of implement disk streaming too, so why not unite the two things ?
In my opinion it would make sense.

I think is is a good thing if you people come up with
solutions/proposals for implementing a sampler engine, but in the long
run it would be wise to join our forces and work on highly reusable
modular components like samplelibrary reading libs, sample rendering
engines, patch editors etc.

cheers,
Benno


Il gio, 2002-12-12 alle 12:18, Antti Boman ha scritto:
> Thanks for the responses. Nice to see things are still developing. I'm 
> always a bit too worried about the possibility of good projects being 
> abandoned.
> 
> Benno Senoner wrote:
> > Hi,
> > sorry for my absence, I have to migrate the servers of an ISP (need to
> > finish for christmas)  thus I will not be that much present for the next
> > two weeks. (I promise no high-load situations again for the whole 2003
> > :-) )
> 
> No need to be sorry, I'm in no position to force people do these things :)
> 
> I'm still willing to hop in when GUIs or similar are needed. 
> Unfortunately, my skills in the low level area are still rather... low.
> 
> -a

-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
 

Re: [Linuxsampler-devel] Anything going on?

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

OK, its on
http://www.ecs.soton.ac.uk/~swh/linuxsampler-2002-12-12.tar.gz

I added some patches to make it compile unser gcc3, but it should be OK on
older compilers still.

- Steve

On Thu, Dec 12, 2002 at 10:56:43 +0000, Phil Kerr wrote:
> Can someone pop it on a server somewhere so I can have a play, or if
> it's not too big, < 500k, email me a copy.
> 
> On Thu, 2002-12-12 at 10:57, Steve Harris wrote:
> > On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> > > The cvs is quite outdated..
> > > I cant commit it seems (either i dont underst very well how sourceforge works,
> > > or my account is wrong, or i forgot my password :), so i've sent
> > > the latest tarball to benno and steve...
> > > Benno seems to be quite busy this week, but i hope
> > > he gets to review/upoaded the latest tarball...
> > 
> > I built it OK, but I had some alsa seq realted problems and so couldn't
> > try it. I'l give it another go when I have a chance.
> > 
> > - Steve 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility 
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

-- 
Stephen Harris                    07970 557047
AKT, IAM Research Group          023 8059 2831
University of Southampton, UK
sw...@ec...     http://www.aktors.org/           

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Josh Green wrote:
> Well, I'm still ploding along on Swami development. New devel branch
> is.. well developing :) libInstPatch has some more testing under its
> belt and a Python interface is beginning to form. I'm starting to
> re-work the GUI side of things to make it more pluggable in anticipation
> of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
> SF1). Much of this has still not been committed to CVS, although I would
> be quick to commit it if I knew someone was interested (hint hint).

No-one is. No, seriously, I'm interested :) And ready to test and help.

-a

Re: [Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Thanks for the responses. Nice to see things are still developing. I'm 
always a bit too worried about the possibility of good projects being 
abandoned.

Benno Senoner wrote:
> Hi,
> sorry for my absence, I have to migrate the servers of an ISP (need to
> finish for christmas)  thus I will not be that much present for the next
> two weeks. (I promise no high-load situations again for the whole 2003
> :-) )

No need to be sorry, I'm in no position to force people do these things :)

I'm still willing to hop in when GUIs or similar are needed. 
Unfortunately, my skills in the low level area are still rather... low.

-a

Re: [Linuxsampler-devel] Anything going on?

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

On Wed, Dec 11, 2002 at 11:36:35 -0300, Juan Linietsky wrote:
> The cvs is quite outdated..
> I cant commit it seems (either i dont underst very well how sourceforge works,
> or my account is wrong, or i forgot my password :), so i've sent
> the latest tarball to benno and steve...
> Benno seems to be quite busy this week, but i hope
> he gets to review/upoaded the latest tarball...

I built it OK, but I had some alsa seq realted problems and so couldn't
try it. I'l give it another go when I have a chance.

- Steve 

Re: [Linuxsampler-devel] Anything going on?

[Juan L. <co...@re...>]

On Wed, 11 Dec 2002 15:40:19 +0200
Antti Boman <ant...@mi...> wrote:

> Hi,
> 
> Is anything going on with linuxsampler? I checked out CVS and it showed 
> updates haven't happened fro five weeks. Are you people working on 
> something else or just... hiding? ;)
> 
> -a
> 

The cvs is quite outdated..
I cant commit it seems (either i dont underst very well how sourceforge works,
or my account is wrong, or i forgot my password :), so i've sent
the latest tarball to benno and steve...
Benno seems to be quite busy this week, but i hope
he gets to review/upoaded the latest tarball...

I'd send it to the list, but it doesnt like big posts, so if
anyone else wants it let me know and i'll private-email it!

Juan Linietsky

Re: [Linuxsampler-devel] evo code

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

Il mar, 2002-11-26 alle 00:23, Christian Schoenebeck ha scritto:
> >
> > What does mean expected buffers similar to ASIO etc ? Can you elaborate
> > ?
> 
> AFAIK ASIO uses two buffers which are isolated. One buffer is only accessed 
> for wether reading or writing, never both at the same time. So buffer A gets 
> filled by the disk stream while buffer B is read by the audio thread. After 
> that buffer B gets filled while buffer A is read and so on...
> The time for one period is fixed by the buffer size, sampling rate and audio 
> channels.
> 
> Somebody already posted an article about that, but I haven't found it anymore.
> 
> The advantage of those simple buffers is that you can always expect a fixed 
> buffer size for reading/writing at any time. Whereas with you approach, you 
> always have to check how many bytes are left to read/write and if you have to 
> continue from the beginning of the buffer after accessing some pieces at the 
> end. That's why your way is a bit more CPU hungry but circumvents those 
> latency problems ASIO and Gigasampler has (latency fixed to the buffer size 
> and latency jitter or even higher latency to correct that jitter).

Keep in mind that with variable sample pitch (which is always the case
in a sampler) you will never be able to read an integral number of
samples from the source (the sample on disk or ram) resample them and
write it to as you call it to the "asio buffer". 
In my code I use OSS or ALSA writing data in chunks too (fragments),
thus it is excactly the stuff you described.
Thanks to the wraparound concept, the overhead is really small since the
buffer ptr updates are very infrequent and occur in a low priority
thread.(the disk thread).

> 
> > If you you have a more efficient scheme in mind please tell us.
> > The final latency does not depend on the ringbuffer size since this
> > buffer is only for compensating disk latency.
> 
> Of course not, I meant those ASIO/Giga Buffers.
but this is user selectable , no problem here, ... As said before, I
successfully ran tests
with 3 x 32 sample audio buffers which leads to 2.1 msec latency. :)
> 
> > On the audio side we simply use regular fragment-based audio output.
> > This means usually only 2-3 fized sized buffers so no ring buffers are
> > involved.
> 
> I guess you mean these audio_sum, audio_buf arrays [audiothread.cpp] to 
> calculate the mix and send it to the audio device, right?

yes.

> >
> > The check_wrap is suboptimal since it checks for when it is about time
> > to replicate some data past the buffer end so that the interpolator can
> > fetch samples past the "official ring buffer end boundary".
> 
> Why is this inefficient? Do you mean because of the memcpy() in check_wrap() 
> that copies a portion within the buffer?

Not the function itself is inefficient, only the fact that it is called
relatively often from within the audiothread. The check_wrap can be
moved to the audio thread where it will be called less frequently thus
saving some cpu cycles (but not that much since it is inlined).

> 
> > This check can be moved within the disk thread which accesses the buffer
> > with a much lower frequency and where it is easy to figure out when the
> > last read reached the ring buffer end position.
> 
> I'm not sure what you're getting at. Do you mean that it's more likely that 
> read/write access to the buffer won't interfere/overlap, because the audio 
> thread reads faster than the disk buffer can fill up the space, due to the 
> higher priority of the audio thread?

no, the disk thread "always writes faster than the audio thread reads",
or in short: there will be always some data in the ring buffer as long
as the disk is not overloaded (if that happens we must lower the max #
of voices or user more powerful hardware ... it is not our fault).
Anyway since in regular conditions there will always some data in the
buffer, resampling will work perfectly even at buffer boundaries thanks
to the check_wrap func that mirrors the data that is stored at the
buffer beginning to the position that resides past the buffer end.

cheers,
Benno


-- 
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
 

Re: [Linuxsampler-devel] Anything going on?

[Josh G. <jg...@us...>]

On Wed, 2002-12-11 at 05:40, Antti Boman wrote:
> Hi,
> 
> Is anything going on with linuxsampler? I checked out CVS and it showed 
> updates haven't happened fro five weeks. Are you people working on 
> something else or just... hiding? ;)
> 
> -a
> 
> 

Well, I'm still ploding along on Swami development. New devel branch
is.. well developing :) libInstPatch has some more testing under its
belt and a Python interface is beginning to form. I'm starting to
re-work the GUI side of things to make it more pluggable in anticipation
of new formats being added to libInstPatch (DLS2, Akai, GUS and perhaps
SF1). Much of this has still not been committed to CVS, although I would
be quick to commit it if I knew someone was interested (hint hint).
Cheers.
	Josh Green

[Linuxsampler-devel] Anything going on?

[Antti B. <ant...@mi...>]

Hi,

Is anything going on with linuxsampler? I checked out CVS and it showed 
updates haven't happened fro five weeks. Are you people working on 
something else or just... hiding? ;)

-a