linuxsampler-devel

[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

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

Things are still happening (was: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post)

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

On Mon, 2003-01-20 at 08: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.)  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:
> 

Swami is still going.. Unfortunately with just me as the developer it is
going somewhat slow. I've been a little burnt out on it lately so I'm
kind of taking a break (sometimes I find that I'm almost working on it
full time). This is hard when I realize I actually have to make money to
live (I haven't received 1 donation yet for Swami, although it hasn't
really been massively released yet.. Maybe the PayPal link is broken or
something, could someone test it? He he..). It would be cool if the
Linux audio community could actually make a living on open source
software development. We need to come up with other methods of raising
money though (grants, money pools, etc).

I already started implementing DLS2 support in libInstPatch. There is
now a generic RIFF parser that can be used for SoundFont files, DLS2 and
other RIFF based formats. The GUI is becoming more pluggable to make
plugging new formats into it rather easy (making a good API design takes
a lot of effort though).

So things are still progressing, just to assure all of you of that. I've
kept quiet because the development version is still not quite usable
(too much in development). The GTK1.2 branch works great though, and the
CVS version works with the most recent FluidSynth (well at least last
time I checked, FluidSynth is also undergoing massive API changes).

So. Keep the Linux music/audio dream alive and let everyday make it more
of a reality :) Cheers.
	Josh Green

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

[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 18.15, Mark Knecht wrote:
> David & David,
>    Was that the name of a band in the late 80's maybe? I must go
> look.

Well, I was just in my early teens back then, so I had nothing to do=20
with it... ;-)


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

Yeah, that's nice - and even Benno chimed in; long time no see! :-)


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

Well, I'm not very familiar with Battery, but maybe Audiality will be=20
able to do what you want rather easily? It's basically a sampler with=20
an integrated mixer. Although the primary source of waveforms is a=20
script driven off-line synth (modular synth style), it can load and=20
process audio files as well. (Which is a feature that remains from=20
Audiality's days as a games sound FX engine.)

As to UI, the scripts is as close as you get right now. There's no=20
GUI at all for it yet, but I have detailed plans for an editor.

That said, I've created almost a hundred "useful" sounds while=20
playing around with the synth. A standard text editor turns out to=20
work a lot better than I ever imagined it could! :-) (Though, my=20
previous synth programing experience is mostly with tiny LCDs and=20
buttons, and a few Windoze synth editors that only made things *more*=20
awkward.)

Anyway, Audiality is still in early beta, and there are a bunch of=20
features that need to be implemented before it's truly useful. I=20
wrote some demo songs a long time ago, so it's not *totally* useless,=20
but let's just say, the sampler part is *really* rudimentary.


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

We're thinking of *everything* that could process or generate audio,=20
though the primary target is synths and samplers. (We already have=20
LADSPA for effects and JACK for applications/"large scale plugins".)=20

Think of XAP as a truly Free VSTi or DXi alternative.


//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

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Monday, January 20, 2003 10:33 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> Well, I'm not very familiar with Battery, but maybe Audiality will be
> able to do what you want rather easily? It's basically a sampler with
> an integrated mixer. Although the primary source of waveforms is a
> script driven off-line synth (modular synth style), it can load and
> process audio files as well. (Which is a feature that remains from
> Audiality's days as a games sound FX engine.)
>
I don't know much of anything about Audiality, except for I have a hard time
spelling it! ;-)

Really, the web page looks interesting, but I've never tried to use it. My
focus (in this specific conversation) really initiated from the idea that
linux would benefit from have a simple app that starts from a base of audio
samples, as opposed to a synth of some type, and knows enough about MIDI,
envelopes and processing to be interesting and useful.

This is where I'm coming from on this specific day, which is not to say I'm
not interested in other things, but this is a linux-sampler, after all. ;-)

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

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

On Monday 20 January 2003 22.52, Mark Knecht wrote:
[...]
> I don't know much of anything about Audiality, except for I have a
> hard time spelling it! ;-)

Yeah - weird name, isn't it? :-)


> Really, the web page looks interesting, but I've never tried to use
> it.

Well, if you're command line challenged, as you say, you should=20
probably wait 'till there's a GUI for it. ;-)


> My focus (in this specific conversation) really initiated from
> the idea that linux would benefit from have a simple app that
> starts from a base of audio samples, as opposed to a synth of some
> type, and knows enough about MIDI, envelopes and processing to be
> interesting and useful.

I see. Reading your other post, it seems like most of what you've=20
mentioned is either implemented or high on the TODO list for=20
Audiality (obviously, since I'm actually going to *use* this myself=20
:-) - but I don't know when I'll get around to hack some form of GUI.=20
It's not a top priority for me, since creating sounds from scratch is=20
workable with a text editor, and loading WAVs is one trivial line of=20
script per file.


> This is where I'm coming from on this specific day, which is not to
> say I'm not interested in other things, but this is a
> linux-sampler, after all. ;-)

Yes - and it seems like "Battery emulation" would be a rather useful=20
starting point that still isn't way beyond reach. I'm afraid most of=20
the work is in the GUI programming domain, though. The parts that=20
deal with what you mentioned are really the trivial parts in=20
Audiality, and that's the case with most audio applications. Most of=20
the complexity in Audiality is stuff that synths generally don't=20
have; such as the fully configurable mixer, the off-line synth and=20
the script interpreter that drives it.


//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

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Monday, January 20, 2003 3:06 PM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
> > My focus (in this specific conversation) really initiated from
> > the idea that linux would benefit from have a simple app that
> > starts from a base of audio samples, as opposed to a synth of some
> > type, and knows enough about MIDI, envelopes and processing to be
> > interesting and useful.
>
> I see. Reading your other post, it seems like most of what you've
> mentioned is either implemented or high on the TODO list for
> Audiality (obviously, since I'm actually going to *use* this myself
> :-) - but I don't know when I'll get around to hack some form of GUI.
> It's not a top priority for me, since creating sounds from scratch is
> workable with a text editor, and loading WAVs is one trivial line of
> script per file.

The value of GUI's early is marketing, and I don't think that's important
right now.

I actually do agree and believe that there's a lot value starting with good
scripts and testing the features BEFORE you invest in a GUI. Let's go after
that first. I'll go look more at what's there in Audiality. My initial worry
was that it was a sequencer, and wanted to be a master and not an
instrument. If it can respond to external MIDI, then it looks like it's got
many of the other interesting things today.

I'm not clear about whether you, David, see this as a linux-sampler project.
I did, but it doesn't matter to me. Give me some instructions and scripts
and either way I'll go test it. However, I think there is value in having a
linux-sampler project at this scale. Something that could be put together
rather quickly, tested pretty easily, to get more people interested in the
whole program overall. With small samples it would run out of memory, but
with larger samples it would have to stream from disk. Getting to the point
where we could do that would be cool. I also think it would help ring out
bugs in the engine.

As GUI's go I think that Battery's is pretty straight forward. They have
something like 50 boxes on the screen. Each box corresponds to a specific
MIDI note and channel. You just load a sound in each box and go. Each box in
Battery has an ADSR, some plugin capabilities and other things, but to start
we just make a matrix of 5x10 or so, load some wave files and go. That would
be a useful device unto itself. The rest could come later when we've seen
the underlying sample playback engine working.

To clarify a couple of things:

1) It's a Jack app
2) It really should handle stereo wave files for samples from day 1
3) Should either have a hard audio panner built into each box, or better
yet, respond to MIDI panning, volume and velocity events. Don't bother with
multiple samples per box (velocity chooses them) until we've seen it run.

I completely believe this could be script driven in the beginning, and
possibly stays that way under the hood even longer term.

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

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

On Tuesday 21 January 2003 00.48, Mark Knecht wrote:
[...GUI...]
> > It's not a top priority for me, since creating sounds from
> > scratch is workable with a text editor, and loading WAVs is one
> > trivial line of script per file.
>
> The value of GUI's early is marketing, and I don't think that's
> important right now.

That's a good point. Also, most serious users care more about quality=20
and features, so having something that can do the job is wort a lot=20
more than having something that looks cool, but doesn't cut it.


> I actually do agree and believe that there's a lot value starting
> with good scripts and testing the features BEFORE you invest in a
> GUI.

Yeah, you might actually get it *right*! :-) (And rebuilding GUIs=20
ain't all that fun...)


> Let's go after that first. I'll go look more at what's there
> in Audiality. My initial worry was that it was a sequencer, and
> wanted to be a master and not an instrument.

It contains a MIDI player, but that's it. It was originally meant for=20
playing SFX and music in a game - and I just can't stand MODs these=20
days, and didn't want to rely on SoundFonts, so I decided to use MIDI=20
+ samples instead. Using the sequencer and the off-line synth is=20
optional, although you have to use either the C API or scripting (the=20
latter is definitely preferred most of the time) to load WAVs and=20
tweak patch parameters, if you have to.


> If it can respond to
> external MIDI, then it looks like it's got many of the other
> interesting things today.

Check - and it even maps the new mixer no NRPNs, so you can configure=20
routing and FXs the way you like directly from the sequencer. There's=20
nothing I hate as much as having to fiddle with all machines to=20
switch between songs and projects... Just making sure to play the=20
init beat of a song is so much smoother. :-)

The only "serious" issue right now is that it's all integer/fixed=20
point processing; not float32. That means you have 16 bits per synth=20
voice (if even that) and 24 bit integer mixing. Maybe sufficient for=20
most work, but you can't make use of 24 bit samples as it is now.

I intend to add full FP support soon, and I might drop the integer=20
support altogether. It's getting more and more pointless, considering=20
what will be "low end hardware" in a few years. Audiality can't=20
compete with a simple MOD player on Pentium and 486 CPUs anyway, and=20
I'm getting more and more bored with that awful integer code, special=20
handling of compilers w/o 64 bit int support and whatnot.

On modern CPUs, the choice of algorithms impacts the CPU usage much=20
more than integer vs float, so for new games, Audiality will still be=20
a viable option - just don't use convolution based reverbs! ;-) Use=20
something else for Pentiums, or help maintain the integer support in=20
Audiality. :-)


> I'm not clear about whether you, David, see this as a linux-sampler
> project.

It's an independent project which I've been working on for a little=20
more than a year, as part of a game. I don't know if it makes sense=20
merging the projects (different priorities, "Choice is Good" and all=20
that), but it's probably a good idea to share ideas, knowledge and=20
perhaps some code.

BTW, lots of ideas and even som code for XAP comes from Audiality.=20
It's entirely possible that I'll split it into a XAP host and some=20
XAP plugins, given that it's basically structured like that=20
internally anyway; it's just not as formal as a plugin API, and=20
doesn't do dynamic loading.


> I did, but it doesn't matter to me. Give me some
> instructions and scripts and either way I'll go test it.

Well, 0.1.0 lacks "waveform mapping", so you can't have more than one=20
waveform per patch. (Right; the demo songs use one channel for each=20
drum sound... *hehe*) You might want to wait for 0.1.1, but I'm not=20
sure when I'll release it.

Could make a development snapshot, though, as it's back in a=20
functional state now. Most interesting news would be some docs, some=20
envelope generator bug fixes, a much more powerful mixer (with a nice=20
NRPN interface) and perhaps most interestingly to testers; a demo app=20
that loads all sounds I've=A0created so far, and sets the engine up as=20
a MIDI synth. All you have to do is hack the main loader script to=20
load your WAVs instead.


> However, I
> think there is value in having a linux-sampler project at this
> scale. Something that could be put together rather quickly, tested
> pretty easily, to get more people interested in the whole program
> overall. With small samples it would run out of memory, but with
> larger samples it would have to stream from disk. Getting to the
> point where we could do that would be cool. I also think it would
> help ring out bugs in the engine.
>
> As GUI's go I think that Battery's is pretty straight forward. They
> have something like 50 boxes on the screen. Each box corresponds to
> a specific MIDI note and channel. You just load a sound in each box
> and go. Each box in Battery has an ADSR, some plugin capabilities
> and other things, but to start we just make a matrix of 5x10 or so,
> load some wave files and go. That would be a useful device unto
> itself. The rest could come later when we've seen the underlying
> sample playback engine working.

Sounds like about a day's work to get the required features into=20
Audiality - but the GUI is more work. Maybe not too far from what I'm=20
going to implement anyway, though...

The GUI editor I have in mind will basically be a hybrid between a=20
text editor and a modular synth editor. When it sees constructs it=20
understands, it displays them as graphical editors instead of text,=20
so you can edit envelopes, maps and other stuff in a smoother manner.=20

"Maps" is what rang a bell. What you're describing is basically a=20
mapping editor of sorts. A map is an object that selects things from=20
an array, based on some criteria. For example, you could hack a patch=20
script that to other patches, based on pitch. Each of those patches=20
could then map to different waveforms, based on velocity.

In the most primitive form, you can just hack something that outputs=20
a script that sets up the mappings and EGs and loads the waveforms.=20
For something more sophisticated, make that an application with=20
access to Audiality's C API, so you can pass the generated script=20
directly, for instant response.


> To clarify a couple of things:
>
> 1) It's a Jack app

Planned, and shouldn't be too hard.


> 2) It really should handle stereo wave files for samples from day 1

Audiality did stereo samples before it got the name. :-) It's really=20
just because the original sound FX samples for that game were in=20
stereo, but it's a nice feature.

That said, I'll probably switch to mono internally (two voices for=20
stereo), since mono + stereo is yet another 2x cases for the voice=20
resamplers. (There are currently 40 of them, to support 8/16 x=20
mono/stereo and 5 quality modes... Lots of macro magic there! *heh*)=20
This is another relic from the days as a low end games SFX engine.


> 3) Should either have a hard audio panner built into each box, or
> better yet, respond to MIDI panning,

Check.


> volume

Check.


> and velocity events.

Check.


> Don't bother with multiple samples per box (velocity chooses them)
> until we've seen it run.

Well, I'll probably get that for free. I'm thinking about creating a=20
generic "mapper" object. Just give it a number and it hands you a=20
number back. Then use that to select patches or waveforms based on=20
whatever parameter you like; MIDI CCs, velocity, pitch or whatever.


> I completely believe this could be script driven in the beginning,
> and possibly stays that way under the hood even longer term.

Yeah, that's kind of handy. Though I wouldn't recommend inventing a=20
custom language and implementing an interpreter for it, unless you=20
*really* need to. I did it because I'm interested in that kind of=20
stuff, and because I wanted a streamlined syntax that I like, and the=20
ability to run scripts reliably in RT context. Still work to do on=20
the latter, though; need to switch to bytecode first of all.

Anyway, a big advantage with using scripts for the interface is that=20
you can change the way things work without hacking and recompiling=20
the GUI or the engine. That's really the main reason why I=20
implemented it in Audiality in the first place; I could edit and test=20
sounds and music in-game without even restarting the game.

It's also cool stuff for "power users", who like to play around with=20
things not meant for ordinary users. :-)


//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

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

On Mon, 2003-01-20 at 09:15, Mark Knecht wrote:

<cut>

> 
>    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?
> 

What do you find lacking with iiwusynth and drum sets? If you are
talking of creating drum sets its probably more of the patch editor that
needs to be up for this task. I have had a number of ideas in the area
of making it easier to create drum kits with Swami. I would like to know
what kinds of features you could envision for your own uses.

<cut>

> 
> Cheers,
> Mark
> 

Cheers.
	Josh Green

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

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

Josh,
   Hi. I'm not much of a fluid-synth user yet, but I'll outline the things I
think I look to battery for:

1) An up front GUI that's pretty easy to see and understand (important for
us 'command-line challenged' types!)
2) Uses 16 & 24-bit wave files easily
3) Assigns specific samples to both specific MIDI notes AND channels. Has
tuning, ADSR envelope plus limited plug in support for each note.
4) Velocity support - maps velocity to different samples. (VERY important
for using .gig files. Not typical of sound font based tools.)
5) Easy to mix samples from different sets to make a new set.

   I would really be happy if Swami might start by reading .gig files and
allowing me to export things like a kick from one set and a snare from
another, save them and load them in a Battery like tool.

   I hope this gives you some ideas.

Cheers,
Mark

> -----Original Message-----
> From: Josh Green [mailto:jg...@us...]
> Sent: Monday, January 20, 2003 11:53 AM
> To: Mark Knecht
> Cc: lin...@li...; Swami Devel
> Subject: RE: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Mon, 2003-01-20 at 09:15, Mark Knecht wrote:
>
> <cut>
>
> >
> >    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?
> >
>
> What do you find lacking with iiwusynth and drum sets? If you are
> talking of creating drum sets its probably more of the patch editor that
> needs to be up for this task. I have had a number of ideas in the area
> of making it easier to create drum kits with Swami. I would like to know
> what kinds of features you could envision for your own uses.
>
> <cut>
>
> >
> > Cheers,
> > Mark
> >
>
> Cheers.
> 	Josh Green
>
>

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

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

On Mon, 2003-01-20 at 13:42, Mark Knecht wrote:
> Josh,
>    Hi. I'm not much of a fluid-synth user yet, but I'll outline the things I
> think I look to battery for:
> 
> 1) An up front GUI that's pretty easy to see and understand (important for
> us 'command-line challenged' types!)

Thats basically what Swami is (and much more really, its an entire API
framework for manipulating patch formats, with a GUI as one of the
interfaces).. It has a FluidSynth plugin to use it as its wavetable
synth engine (currently the only supported one, but I will be adding a
hardware EMU8k/10k plugin in the future). Of course Swami still needs a
bit of work to make it the best patch editor in the world :)

> 2) Uses 16 & 24-bit wave files easily

Swami currently only supports SoundFont files (I'm just now adding DLS2
support). SoundFont uses 16 bit data only, DLS2 officially only supports
8 or 16 bit data, but the format could in theory accomodate 24 bit or
other formats. They just wouldn't be portable (DLS2 does have support
for conditional proprietary stuff).

> 3) Assigns specific samples to both specific MIDI notes AND channels. Has
> tuning, ADSR envelope plus limited plug in support for each note.

Yes to everything.. Except that MIDI channel mapping is usually done by
selecting Bank:Preset pairs which are specific instruments or banks of
drums (not built into the format). Drums are traditionally only on MIDI
channel 10, although SoundFont does not restrict this. Plugin support
for each note? Not sure what you mean by that, but FluidSynth does have
a LADSPA host for adding LADSPA plugins to the synthesis output (no GUI
support for this yet though).

> 4) Velocity support - maps velocity to different samples. (VERY important
> for using .gig files. Not typical of sound font based tools.)

Yes.. Swami has this already. Each zone can have its own velocity range
which causes the sound to play, can also layer velocity/key range zones.

> 5) Easy to mix samples from different sets to make a new set.
> 

Swami can open multiple patch files and easily copy samples/instruments
between them, if this is what you mean.

>    I would really be happy if Swami might start by reading .gig files and
> allowing me to export things like a kick from one set and a snare from
> another, save them and load them in a Battery like tool.
> 

I don't know much about .gig files, but I heard someone mention they are
based on DLS2. If this is the case it might be easy to add support for
them after DLS2 support is finished.

>    I hope this gives you some ideas.

Sure.. A lot of this is already available though.. Have you tried
Swami/FluidSynth? The current CVS is GTK1.2 based and works with
FluidSynth CVS (at least last time I checked). Development is currently
happening on the CVS swami-1-0 branch, but it isn't operational quite
yet.

> 
> Cheers,
> Mark
> 

Cheers.
	Josh Green

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

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

On Tue, 2003-01-21 at 01:35, Josh Green wrote:
>
> Swami currently only supports SoundFont files (I'm just now adding DLS2
> support). SoundFont uses 16 bit data only, DLS2 officially only supports
> 8 or 16 bit data, but the format could in theory accomodate 24 bit or
> other formats. They just wouldn't be portable (DLS2 does have support
> for conditional proprietary stuff).
> 
If you're interested in the .gig format, you can get lots of files at

http://www.worrasplace.com

He's got a nice selection of large and small ones. 

I know nothing of the internal format of the file, but I suspect that
there are web sites out there with info.

Cheers,
Mark

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

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

Josh,
   Hi. Removed iiwusynth-devel as I am not a member of that list.

   I like what I see in Swami so far. It reminds me of parts of the
GigaStudio editing interface where you build your own .gig files. It
doesn't have all of the velocity mapping stuff, but most of it seems to
be there.

   The thing I see in Swami right now, and forgive me if I'm wrong about
this after just a short read through, is that it appears oriented to
dealing with samples and libraries, as opposed to being a MIDI-based
sample player. (I.e. - and instrument) It does look like it makes using
fluid-synth potentially easier, so I should pay attention to it for that
reason alone I suppose.

   If you want to go look at Battery's interface, it's pretty clean and
to the point. 

http://www.nativeinstruments.de/index.php?id=battery_us

   It's really oriented towards playing short samples, but it can be
used for longer ones also. 

   BTW - I am NOT a Battery owner. I have used it very little. I was
just pointing out that as a sample playing app, it is a model that
people seem to get their hands around quickly. I also think it's ideal
for a first test vehicle for this sampler engine.

   Maybe I'm taking some of the posts here in the wrong light, but yours
and Dave's both seem aimed at getting me to use something that currently
exists, where my idea was to find good uses for this new Linux-Sampler
engine. If I'm off base and people here don't think this is a good use,
then that's OK too. I was just speaking up since this list has been
'very quiet', as the title in my thread indicates!

Cheers,
Mark



On Tue, 2003-01-21 at 01:35, Josh Green wrote:
> On Mon, 2003-01-20 at 13:42, Mark Knecht wrote:
> > Josh,
> >    Hi. I'm not much of a fluid-synth user yet, but I'll outline the things I
> > think I look to battery for:
> > 
> > 1) An up front GUI that's pretty easy to see and understand (important for
> > us 'command-line challenged' types!)
> 
> Thats basically what Swami is (and much more really, its an entire API
> framework for manipulating patch formats, with a GUI as one of the
> interfaces).. It has a FluidSynth plugin to use it as its wavetable
> synth engine (currently the only supported one, but I will be adding a
> hardware EMU8k/10k plugin in the future). Of course Swami still needs a
> bit of work to make it the best patch editor in the world :)
> 
> > 2) Uses 16 & 24-bit wave files easily
> 
> Swami currently only supports SoundFont files (I'm just now adding DLS2
> support). SoundFont uses 16 bit data only, DLS2 officially only supports
> 8 or 16 bit data, but the format could in theory accomodate 24 bit or
> other formats. They just wouldn't be portable (DLS2 does have support
> for conditional proprietary stuff).
> 
> > 3) Assigns specific samples to both specific MIDI notes AND channels. Has
> > tuning, ADSR envelope plus limited plug in support for each note.
> 
> Yes to everything.. Except that MIDI channel mapping is usually done by
> selecting Bank:Preset pairs which are specific instruments or banks of
> drums (not built into the format). Drums are traditionally only on MIDI
> channel 10, although SoundFont does not restrict this. Plugin support
> for each note? Not sure what you mean by that, but FluidSynth does have
> a LADSPA host for adding LADSPA plugins to the synthesis output (no GUI
> support for this yet though).
> 
> > 4) Velocity support - maps velocity to different samples. (VERY important
> > for using .gig files. Not typical of sound font based tools.)
> 
> Yes.. Swami has this already. Each zone can have its own velocity range
> which causes the sound to play, can also layer velocity/key range zones.
> 
> > 5) Easy to mix samples from different sets to make a new set.
> > 
> 
> Swami can open multiple patch files and easily copy samples/instruments
> between them, if this is what you mean.
> 
> >    I would really be happy if Swami might start by reading .gig files and
> > allowing me to export things like a kick from one set and a snare from
> > another, save them and load them in a Battery like tool.
> > 
> 
> I don't know much about .gig files, but I heard someone mention they are
> based on DLS2. If this is the case it might be easy to add support for
> them after DLS2 support is finished.
> 
> >    I hope this gives you some ideas.
> 
> Sure.. A lot of this is already available though.. Have you tried
> Swami/FluidSynth? The current CVS is GTK1.2 based and works with
> FluidSynth CVS (at least last time I checked). Development is currently
> happening on the CVS swami-1-0 branch, but it isn't operational quite
> yet.
> 
> > 
> > Cheers,
> > Mark
> > 
> 
> Cheers.
> 	Josh Green
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

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

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

On Mon, 2003-01-20 at 09:56, Mark Knecht wrote:
> Josh,
>    Hi. Removed iiwusynth-devel as I am not a member of that list.
> 
>    I like what I see in Swami so far. It reminds me of parts of the
> GigaStudio editing interface where you build your own .gig files. It
> doesn't have all of the velocity mapping stuff, but most of it seems to
> be there.
> 

What kind of velocity functionality are you looking for?

>    The thing I see in Swami right now, and forgive me if I'm wrong about
> this after just a short read through, is that it appears oriented to
> dealing with samples and libraries, as opposed to being a MIDI-based
> sample player. (I.e. - and instrument) It does look like it makes using
> fluid-synth potentially easier, so I should pay attention to it for that
> reason alone I suppose.
> 

Currently the GUI is somewhat out-dated compared to the underlying API
architecture. Its currently structured primarily as an editor. But I
have many things on my list to add to make it a better front-end for
FluidSynth (wavetable MIDI channel instrument selections, GUI MIDI
controllers, session modulators, etc). As things are now you can start
up FluidSynth within Swami using the alsa_seq MIDI driver and connect a
sequencer to it (you can do this with FluidSynth stand alone as well).
Also I'm going to be making the layout very dynamic and flexible. The
GUI is already separated into self contained objects. I just need to
create a GUI manager that allows creating new GUI objects, designating
their layout (docked with other elements or in its own dialog, etc) and
setting their view parameters. So you could for instance create multiple
patch tree objects, a couple envelope editors, and define their layout
and save and restore it. This will allow for different setups depending
on if someone is editing, using it as a wavetable bank manager,
sequencing with it, etc.

>    If you want to go look at Battery's interface, it's pretty clean and
> to the point. 
> 
> http://www.nativeinstruments.de/index.php?id=battery_us
> 
>    It's really oriented towards playing short samples, but it can be
> used for longer ones also. 
> 

Yeah, the interface looks nice. I already have a crude envelope editor
in place. I haven't worked on it in a while, but I have been thinking
about making it really flexible and allowing it to be overlayed on the
sample waveform, allowing multiple parameters from different instruments
to be edited simultainiously, etc.

>    BTW - I am NOT a Battery owner. I have used it very little. I was
> just pointing out that as a sample playing app, it is a model that
> people seem to get their hands around quickly. I also think it's ideal
> for a first test vehicle for this sampler engine.
> 

As far as Linuxsampler and Swami are concerned.. Linuxsampler may end up
being a wavetable engine within Swami, as well as my libInstPatch
library being used for accessing patch formats. This all remains to be
seen though.

>    Maybe I'm taking some of the posts here in the wrong light, but yours
> and Dave's both seem aimed at getting me to use something that currently
> exists, where my idea was to find good uses for this new Linux-Sampler
> engine. If I'm off base and people here don't think this is a good use,
> then that's OK too. I was just speaking up since this list has been
> 'very quiet', as the title in my thread indicates!
> 

Sure.. You got things going again :)

> Cheers,
> Mark
> 

Lates..
	Josh Green

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

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of Josh
> Green
> Sent: Tuesday, January 21, 2003 4:25 AM
>
> What kind of velocity functionality are you looking for?
>
Josh,
   I think Markus had it basically right in his follow up email. We need to
be able to map multiple sample sets against a single note, or range of
notes, but choose them based on what MIDI velocity is received. This is the
way all of the good GSt libraries work.

   As an example only, for the piano libraries they may sample the piano at
4, 8 or 16 even different playing key pressures. Then the softest sample is
mapped from a MIDI velocity of 0-31, the second from 32-63, third from
64-95, fourth from 96-127. Within each range the same sample is played, but
the sample's audio volume is adjusted based on the velocity, so that a MIDI
velocity of 93 plays louder than a velocity of 68, but they both play the
same sample.

   The technical issue with these libraries is that sometimes a velocity of
63 and 64 do not compare well with each other, so there are adjustments made
in each sample set to get it all to work. You are going to find these
adjustments in a .gig file I'm sure.

   The other one we need is 'key switching', where a range of keys on the
keyboard are reserved as switches, not notes. When one of these keys is
pressed, the complete sample set for all MIDI velocities changes. I think
this one is easier to implement though. (Famous last words...) You'll find
this in some of the .gig libraries, but possibly not on Worra's site.

Cheers,
Mark

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

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

On Tuesday 21 January 2003 15.51, Mark Knecht wrote:
[...]
>    The other one we need is 'key switching', where a range of keys
> on the keyboard are reserved as switches, not notes. When one of
> these keys is pressed, the complete sample set for all MIDI
> velocities changes. I think this one is easier to implement though.
> (Famous last words...) You'll find this in some of the .gig
> libraries, but possibly not on Worra's site.

That's a very interesting idea... (Especially if you have 88 keys. ;-)

I have NRPN programmable CC->mixer control mapping (so you can hook=20
the mod wheel up to the auto-wah base cutoff or something), but I=20
never thought about mapping *keys*... Or poly pressure. :-)


//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] RE: Hi - Very quiet list - my first post

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Tuesday, January 21, 2003 7:50 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] RE: Hi - Very quiet list - my first
> post
>
>
> On Tuesday 21 January 2003 15.51, Mark Knecht wrote:
> [...]
> >    The other one we need is 'key switching', where a range of keys
> > on the keyboard are reserved as switches, not notes. When one of
> > these keys is pressed, the complete sample set for all MIDI
> > velocities changes. I think this one is easier to implement though.
> > (Famous last words...) You'll find this in some of the .gig
> > libraries, but possibly not on Worra's site.
>
> That's a very interesting idea... (Especially if you have 88 keys. ;-)
>
> I have NRPN programmable CC->mixer control mapping (so you can hook
> the mod wheel up to the auto-wah base cutoff or something), but I
> never thought about mapping *keys*... Or poly pressure. :-)
>

Key switching is used very nicely in most GSt horn libraries today, as well
as in the Scarbee Bass libraries. Here's an idea of what you get:

(Key Switch Map from memory - definitely not correct)

Key-map 	Sample
C-3		Standard notes, long sustain
D-3		Standard note, staccato
E-3		Slide up to note
F-3		Slide down to note
G-3		Trills

It's very powerful and allows a library developer to map lots of useful
stuff into the library without taking up normal note space, and also not
confusing beginning users.

It's a bit cranky when you consider notation capabilities in programs like
Rosegarden. None of them know that these notes are key switches. I've taken
recently to moving key switch notes to a separate track that transmits on
the same channel.

Cheers,
Mark

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

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

On Tuesday 21 January 2003 18.12, Mark Knecht wrote:
[...]
> It's a bit cranky when you consider notation capabilities in
> programs like Rosegarden. None of them know that these notes are
> key switches. I've taken recently to moving key switch notes to a
> separate track that transmits on the same channel.

Well, I'm using piano roll for the few edits I make (I just record=20
and maybe quantize, scale velocities, scale note lenghts etc), and=20
that would work perfecty with key switches, I think.

One thing I just *have* to try is hooking some keys up to f and q of=20
some resonant filters... :-)


//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] RE: Hi - Very quiet list - my first post

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Tuesday, January 21, 2003 9:38 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] RE: Hi - Very quiet list - my first
> post
>
>
> On Tuesday 21 January 2003 18.12, Mark Knecht wrote:
> [...]
> > It's a bit cranky when you consider notation capabilities in
> > programs like Rosegarden. None of them know that these notes are
> > key switches. I've taken recently to moving key switch notes to a
> > separate track that transmits on the same channel.
>
> Well, I'm using piano roll for the few edits I make (I just record
> and maybe quantize, scale velocities, scale note lenghts etc), and
> that would work perfecty with key switches, I think.
>
> One thing I just *have* to try is hooking some keys up to f and q of
> some resonant filters... :-)
>
Dave,
   I hope I wasn't misunderstood. RG, Pro Tools, Cubase SX, they all work
with key switches. I can put key switch events on the same track. They are
sent and cause the sample sets to switch. That does not cause a problem.

   The _only_ problem I've run into is that while you and I understand that
a key switch at C-3 isn't a musical note, a notation program does not, and
will paint a quarter note there when one does not need one musically.

Cheers,
Mark

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

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

On Tuesday 21 January 2003 19.03, Mark Knecht wrote:
[...]
> Dave,
>    I hope I wasn't misunderstood. RG, Pro Tools, Cubase SX, they
> all work with key switches. I can put key switch events on the same
> track. They are sent and cause the sample sets to switch. That does
> not cause a problem.

Yes, that's what's so great with them; they're based on a part of the=20
protocol that you basically *have* to support to control an=20
instrument anyway.


>    The _only_ problem I've run into is that while you and I
> understand that a key switch at C-3 isn't a musical note, a
> notation program does not, and will paint a quarter note there when
> one does not need one musically.

Yeah, I see what you mean, although I'm still not sure whether you're=20
thinking about printing or editing in "staff view". Either way, both=20
have the same problem, although it's probably even more annoying to=20
get it on paper...! ;-)


//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

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

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

[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