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

[Linuxsampler-devel] specify alsa device?

[Garett S. <shu...@co...>]

Hello, Is it possible to specify an alsa device (like something setup in 
asouncrc) for the sampler or a channel? What does the sampler default 
to? hw:0,0? Thanks. -Garett

[Linuxsampler-devel] Latest CVS commit

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

Hi!

I hope the worst bugs in latest version are now fixed. Let me know if you 
still found some!

Changes:

	* src/Sampler.cpp: fixed 3 stupid but fatal bugs that left in the
	  rush (in method SamplerChannels(), CreateAudioOutputDevice() and
	  CreateMidiInputDevice())

	* src/network/lscpserver.cpp: implemented LSCP command
	  'SET CHANNEL MIDI_INPUT_CHANNEL'

	* src/Sampler.h: moved enums 'audio_output_type_t',
	  'midi_input_type_t' and 'engine_type_t' into the respective base
	  classes ('AudioOutputDevice', 'MidiInputDevice', 'Engine')

CU
Christian

[Linuxsampler-devel] Latest CVS commit

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

Changes:

	* src/common/Thread.cpp: threads are now stoppable even if they are
	  waiting for a condition
	  
	* src/common/Condition.cpp: fixed little misbehavior of Set()
	  method, which locked the Condition object on return
	  
	* src/testcases: added a couple of new unit tests (against classes
	  'Mutex', 'Condition' and 'Thread')

CU
Christian

Re: [Linuxsampler-devel] simplest control interface?

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

Es geschah am Dienstag, 4. Mai 2004 00:00 als Garett Shulman schrieb:
> Hello, I have checked out the linux sampler source from cvs, built, &
> installed it. I can access the server with the python sockets module.
> However, I was wondering what the easiest way to control the sampler
> currently is? It seems that the cvs version does not accept any options
> when starting and only starts with the server. It seems that there is no
> other way to access the sampler than through the network sockets. Is
> there a simple cli client that would allow me to send and receive
> control protocol data? Thanks. -Garett

The easiest way currently is to write a LSCP script and to send it via
netcat to the running sampler:

	cat yourscript.lscp | nc -t localhost 8888

or you can of course simply connect via telnet ('telnet localhost 8888') and
write the LSCP commands manually. Rui is working on a Qt based GUI fronted
for LinuxSampler, but it's not finished yet. And note that recent LS version
is still a bit buggy, due to the recent transition to multi channel support,
so you simply might use the old single channel version of LinuxSampler for
the moment which also has the old command line parameters. You can checkout
the old version by doing:

	cvs -z3 -d:pserver:ano...@cv...:/var/cvs/linuxsampler co -r v0_1_0 linuxsampler

CU
Christian

P.S. btw sorry in my last mail the CVS command line was wrong; it should be
'-d:pserver:anonymous' instead of 'd:pserver:schoenebeck' of course.

[Linuxsampler-devel] simplest control interface?

[Garett S. <shu...@co...>]

Hello, I have checked out the linux sampler source from cvs, built, & 
installed it. I can access the server with the python sockets module. 
However, I was wondering what the easiest way to control the sampler 
currently is? It seems that the cvs version does not accept any options 
when starting and only starts with the server. It seems that there is no 
other way to access the sampler than through the network sockets. Is 
there a simple cli client that would allow me to send and receive 
control protocol data? Thanks. -Garett

[Linuxsampler-devel] Latest CVS commit

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

Changes:

	* src/common/Thread.cpp: method StartThread() now blocks until thread
	  actually runs, mlockall() will only be applied for realtime threads

	* libtoolized liblinuxsampler

	* initiated automatic unit tests against the LinuxSampler codebase
	  (see src/testcases): already added a couple of tests for the Thread and
	  Mutex classes, you have to explicitly compile the unit tests by running
	  'make testcases' (you need to have cppunit installed though) and then you
	  can run the console version of the test runner by calling
	  'src/testcases/linuxsamplertest'

	* src/Sampler.h: added API documentation

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler GUI spec.

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

Hi Mark,

>
>    Great start.
>

Thanks, and it's just that, a start :)

>
>    From a user's perspective, let me suggest a 'Mute' button and a
> 'Solo' button on each sampler channel. Also, mostly for ease of setup,
> it would be very helpful to have an LED that shows MIDI activity on this
> specific sampler channel. Not sure if this is possibly your 'Stream
> usage' item. I think this activity light could share space with mute and
> just flash when there's activity, but be lit all the time when muted.
>

Please note that I've stuck with the available LSCP specification, and
there's no command (yet) to handle the mono/solo channel mode nor MIDI
activity.

However the mono/solo modes may be emulated on the client by juggling with
the volume setting. Is this workaround acceptable or consensual?

>
>    Gst 2.5 offers both tuning and panning sliders, and also a feature
> I've never used where you can change these sliders to have a connection
> to any MIDI controller value. (At this level my MIDI capabilities are
> pretty minimal.) This is true for the volume slider also.
>

Again, the client sits exclusively on top of the LSCP layer (liblscp). If
LSCP does not provide the intended functionality, the client is left in
the blind for that matter. Period. Remember that the linuxsampler server
and the GUI client may not reside on the same node/machine.

My assertion is that the client must behave and expose the very same
functionality whether it's on same local machine or on the other side of
the world, in regard to the LS server.

Therefore, any additional accessability feature (in client software terms,
not user ones :) must be defined and supported on a future LSCP
specification and implementation.

We'll get there, eventually, and we're just starting with the basics, and
there's plenty to do already.


>
>    I think that your Instrument will need to be more selective than just
> a file name since gig file contain many instruments, etc. We need to see
> the actual instrument chosen from within the gig file.
>

Of course. The idea is that once a file is selected for loading into a
channel, via a traditional file-open dialog, it's type and format are
checked and, in case of a gig file, an instrument-index selection dialog
is in order. I assume that libgig will come to the rescue.

>
>    One could argue the value, if they wanted to, for the ability to
> insert a plugin at this point. I'd probably reserve that for the mixer
> GUI.
>

Yep. That's yet another feature ..)

>
>    I'll wait for your suggestions on other GUI pages such as the mixer,
> loaded instruments as they will likely be quite good.
>

They'll come, as further development progresses... slowly. Please be
(very) patient :) Note that my GUI proposal is neither complete nor final,
whatsoever. And considering it, I know it doesn't make justice as the
professional-grade product comparable to linuxsampler's ambitions. Yet. As
said, it's just a start.

This is not an excuse for not willing to work on your suggestions. In
fact, it's just the opposite. It's just pragmatism running free ;)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] LinuxSampler GUI spec.

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

Hi Rui,
   Great start. 

   From a user's perspective, let me suggest a 'Mute' button and a
'Solo' button on each sampler channel. Also, mostly for ease of setup,
it would be very helpful to have an LED that shows MIDI activity on this
specific sampler channel. Not sure if this is possibly your 'Stream
usage' item. I think this activity light could share space with mute and
just flash when there's activity, but be lit all the time when muted.

   Gst 2.5 offers both tuning and panning sliders, and also a feature
I've never used where you can change these sliders to have a connection
to any MIDI controller value. (At this level my MIDI capabilities are
pretty minimal.) This is true for the volume slider also.

   I think that your Instrument will need to be more selective than just
a file name since gig file contain many instruments, etc. We need to see
the actual instrument chosen from within the gig file.

   One could argue the value, if they wanted to, for the ability to
insert a plugin at this point. I'd probably reserve that for the mixer
GUI.

   I'll wait for your suggestions on other GUI pages such as the mixer,
loaded instruments as they will likely be quite good.

Thanks,
Mark


On Thu, 2004-04-29 at 03:59, Rui Nuno Capela wrote:
> Hi all,
> 
> Here goes, at least under my point of view 8)
> 
> 
> Preliminar specification for the LinuxSampler GUI application
> -------------------------------------------------------------
> 
> According to current LSCP document draft (v.04), and the corresponding
> iblscp implementation, the following notes apply as proposed requirements
> for the primordial LinuxSampler GUI application.
> 
> 
> a)  Each sampler channel maps to one strip on the main GUI control panel,
>     whithin the main application window.
> 
> b)  Sampler channel strips may be stacked on either a vertical (like a
>     mixing desk) or horizontal layout (like a studio rack).
> 
> c)  Channel strips are added or removed at will.
> 
> d)  Each sampler channel strip shall have the following GUI controls:
> 
>  1. Engine        : string  <engine-name>   : option list.
> 
>  2. Instrument    : string  <filename>      : button; fileopen dialog.
> 
>  3. MIDI Type     : "alsa"                  : option list.
> 
>  4. MIDI Port     : string  <midi-port>     : edit box.
> 
>  5. MIDI Channel  : int     <midi-channel>  : option list.
> 
>  6. Audio Type    : "alsa" | "jack"         : option list.
> 
>  7. Audio Channel : int     <audio-channel> : edit spinbox.
> 
>  8. Volume        : float   <volume>        : knob/slider; edit spinbox.
> 
>  9. Voice Count   : int                     : display.
> 
> 10. Stream Usage  : int[]                   : display; chart.
> 
> 11. Reset         :                         : button.
> 
> 
> e)  The complete session state might be saved and loaded from the local
>     file system, as plain LSCP script documents.
> 
> f)  The application setup options dialog include the linuxsampler server
>     hostname and port specification with option to auto-start the server
> locally (localhost), where the corresponding startup command-line may be
> user editable.
> 
> g)  The main application window may follow the SDI model, with regular
>     menu, tool and status bars. The proposed initial menu hierarchy:
> 
>     File
> 
>         New             Start a new session state from scratch.
>         Open...         Load a session from an existing LSCP file.
>         Save            Save current state to a LSCP file.
>         Save As...      Save current state with an alternate name.
>         -               -
>         Quit            Quit application.
> 
>     Edit
> 
>         Add Channel     Add a new channel strip to current session.
>         Remove Channel  Remove selected channel strip from session.
>         -               -
>         Reset Channel   Reset currently selected sampler channel.
> 
>     View
> 
>         Show Menubar    Show/Hide the main window menubar.
>         Show Toolbar    Show/Hide the main window button toolbar.
>         Show Statusbar  Show/Hide the main window statusbar.
>         -               -
>         Show Messages   Show/Hide the messages log window (debug).
>         -               -
>         Options...      General options setup dialog.
> 
>     Help
> 
>         About...        Self-credits show off.
> 
> 
> Think this is enough, for the time being.
> 
> Yet again, another important question remains, which deals with the
> "official" application name. My proposals goes to, in strict biased
> descending order of preference:
> 
>     qsampler
>     qls
>     qlinuxsampler
>     lsgui
>     linuxsamplergui
> 
> Of course, those "q" prefixes comes from my reliance to Qt :)
> 
> So, make up your minds, ppl.
> 
> Cheers.

Re: [Linuxsampler-devel] LinuxSampler GUI spec.

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

Hi Vladimir,

>
> I've been thinking . . . for option lists such as engine, midi type,
> audio type and maybe even midi ports and instruments we may want some
> commands in LSCP to allow the client to figure out what server supports
> or has available. We already have GET AVAILABLE_ENGINES
> Should we also add:
> GET AVAILABLE_MIDITYPES
> GET AVAILABLE_MIDIPORTS
> GET AVAILABLE_AUDIOTYPE
> GET AVAILABLE_INSTRUMENTS
>
> This will allow the GUI to have less hard coded values and be more
> compatible with different versions of LS.
>

Yep, soon or later some of these will be quite handy.

votes++;

However the GET AVAILABLE_INSTRUMENTS command is surely prone to disparate
views. No vote here ;)

IMHO the best approach is that LOAD INSTRUMENT would be the proper place
to accept a regularly formed URI (e.g.
proto://hostname/directory/filename). Of course, this surely need support
on the linuxsampler server side.

The client just feeds the URI literally (it does not stream any data
whatsoever, just the LOAD INSTRUMENT command), but the UI may help a
little (e.g. common fileopen dialog, as of KDE's).


> Speaking about instruments . . . maybe we should also add a few more
> commands:
> ADD INSTRUMENT_LOCATION "url"
> REMOVE INSTRUMENT_LOCATION "url"
> GET INSTRUMENT_LOCATIONS
> RESET INSTRUMENT_LOCATIONS
>
> in this example, locally located instruments will have a location like
> "/mnt/gigs/" we could later add support for other location types such
> as "smb://server/share/dir/", etc. off the box locations may involve
> copying instruments to the local /tmp directory when they are loaded or
> perhaps streaming them over the network?! perhaps i'm just crazy and
> these "other location types" are overkill and nobody will ever need
> them anyway.

Overkill indeed, at least for the moment. But I see your point,
nevertheless. See above.

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] LinuxSampler GUI spec.

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

Es geschah am Mittwoch, 28. April 2004 21:42 als Emiliano Grilli schrieb:
> I'm not a coder and not a very skilled graphic person, but today I have
> asked on an italian forum full of talented 3d graphic skilled guys if
> someone would like to contribute some graphics to this project.
>
> They use primarily blender, and I think they can produce something useful
> in short time, but they need some input: a guy who is very active on the
> forum asked about a pencil sketch of the main idea of the GUI, with (I
> guess) faders, knobs, logos, and so on...
>
> If this can be of any help, it would be fantastic :)

It definitely would!

> Some time ago (remember that I'm not a good designer) I made a blender
> project with some knobs,sliders and leds:
>
> http://www.emillo.net/download/mixer.png

Looks quite good already.

Speaking about blender, doesn't it also provide a way to create OpenGL code or 
something from your 3D scenes? That would of course even be better, to let 
the GUI render the knobs etc. in realtime by the 3D graphics card instead of 
reloading an image from harddisk, because the latter would stress the 
workstation a bit more.


Es geschah am Donnerstag, 29. April 2004 12:59 als Rui Nuno Capela schrieb:
> Hi all,
>
> Here goes, at least under my point of view 8)
>
>
> Preliminar specification for the LinuxSampler GUI application
> -------------------------------------------------------------
[snip]
>  5. MIDI Channel  : int     <midi-channel>  : option list.

which is btw at the moment (current CVS) 1-16 or all channels

>  7. Audio Channel : int     <audio-channel> : edit spinbox.

That's one of the things that has to be changed. All audio channels in LS are 
by definition mono and as some engines (/instruments) need a different amount 
of audio output channels, we have to extend it in such way that we connect 
each engine's (=sampler channel's) audio output channel individually to an 
arbitrary output channel of the audio output device. But the limitiation is 
still of course that each sampler channel is only connected to one audio 
output device, so you would not be able e.g to connect audio output channel 1 
of sampler channel 1 to an output channel of the Alsa device and and another 
output channel of sampler channel 1 to a VSTi device or whatever.

Another important thing the GUI has to manage is to *manually* create audio 
output devices and MIDI input devices. At the moment, when you select an 
audio output type / MIDI input type, LS looks if such a device is already 
created, if yes simply connects to it, if not LS will create such a device 
with default parameters, which is of course handy if you quickly want to 
setup an LS session, but the user should also be able to create those devices 
(and reconfigure and destroy them at a later stage) with custom values, so 
the user can e.g. select 96kHz for sampling rate for the Alsa audio output 
device instead of the default 44.1 kHz. This is not yet covered by LSCP.

>  9. Voice Count   : int                     : display.
>
> 10. Stream Usage  : int[]                   : display; chart.

and we will add Voice Count Max. and Stream Usage Max.

> Yet again, another important question remains, which deals with the
> "official" application name. My proposals goes to, in strict biased
> descending order of preference:
>
>     qsampler
>     qls
>     qlinuxsampler
>     lsgui
>     linuxsamplergui

As long as you don't call it just 'linuxsampler' or 'sampler' I'll be fine 
with any name for the GUI application.

Es geschah am Donnerstag, 29. April 2004 15:03 als Vladimir Senkov schrieb:
> Hi Rui,
> Guys,
>
> I've been thinking . . . for option lists such as engine, midi type,
> audio type and maybe even midi ports and instruments we may want some
> commands in LSCP to allow the client to figure out what server supports
> or has available. We already have GET AVAILABLE_ENGINES
> Should we also add:
> GET AVAILABLE_MIDITYPES
> GET AVAILABLE_MIDIPORTS
> GET AVAILABLE_AUDIOTYPE

Yes

> GET AVAILABLE_INSTRUMENTS

Not sure about that

> Speaking about instruments . . . maybe we should also add a few more
> commands:
> ADD INSTRUMENT_LOCATION "url"
> REMOVE INSTRUMENT_LOCATION "url"
> GET INSTRUMENT_LOCATIONS
> RESET INSTRUMENT_LOCATIONS
>
> in this example, locally located instruments will have a location like
> "/mnt/gigs/"
> we could later add support for other location types such as
> "smb://server/share/dir/", etc. off the box locations may involve
> copying instruments to the local /tmp directory when they are loaded or
> perhaps streaming them over the network?!
> perhaps i'm just crazy and these "other location types" are overkill and
> nobody will ever need them anyway.

I don't see why this could bring us a great benefit. If you prefer a 
collection based instrument selection, I would propose (at least for the 
moment) simply to use a hard coded local directory instead, which is scanned 
by LS when it starts (e.g. /var/sampler) and in this directory you can create 
symlinks as you like to directories which actually contain various instrument 
files.

Streaming from a network location is also nice... one day... ;)

> GET AVAILABLE_INSTUMENTS will perhaps be somewhat similar to "ls". It
> will go thru all configured INSTRUMENT_LOCATIONS and output will perhaps
> look like this:
> /mnt/gigs/i1.gig:0:"Some description"
> /mnt/gigs/i1.gig:1:"Some description"
> /mnt/gigs/i2.gig:0:"Some description"
> smb://gigserver/gigshare/gigs/i3.gig:0:"Some description"
> ftp://anothergigserver/gigs/i4.gig:0:"Something"
>
> Perhaps other fields like sample rate, etc.

Yeah, informations about the instrument file would be nice. But I would also 
postpone that to a later stage.

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler GUI spec.

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

Hi Rui,
Guys,

I've been thinking . . . for option lists such as engine, midi type, 
audio type and maybe even midi ports and instruments we may want some 
commands in LSCP to allow the client to figure out what server supports 
or has available. We already have GET AVAILABLE_ENGINES
Should we also add:
GET AVAILABLE_MIDITYPES
GET AVAILABLE_MIDIPORTS
GET AVAILABLE_AUDIOTYPE
GET AVAILABLE_INSTRUMENTS

This will allow the GUI to have less hard coded values and be more 
compatible with different versions of LS.

Speaking about instruments . . . maybe we should also add a few more 
commands:
ADD INSTRUMENT_LOCATION "url"
REMOVE INSTRUMENT_LOCATION "url"
GET INSTRUMENT_LOCATIONS
RESET INSTRUMENT_LOCATIONS

in this example, locally located instruments will have a location like 
"/mnt/gigs/"
we could later add support for other location types such as 
"smb://server/share/dir/", etc. off the box locations may involve 
copying instruments to the local /tmp directory when they are loaded or 
perhaps streaming them over the network?!
perhaps i'm just crazy and these "other location types" are overkill and 
nobody will ever need them anyway.

GET AVAILABLE_INSTUMENTS will perhaps be somewhat similar to "ls". It 
will go thru all configured INSTRUMENT_LOCATIONS and output will perhaps 
look like this:
/mnt/gigs/i1.gig:0:"Some description"
/mnt/gigs/i1.gig:1:"Some description"
/mnt/gigs/i2.gig:0:"Some description"
smb://gigserver/gigshare/gigs/i3.gig:0:"Some description"
ftp://anothergigserver/gigs/i4.gig:0:"Something"

Perhaps other fields like sample rate, etc.

config file on the server (or command line options) will perhaps limit 
the availability of audio types, midi types and ports and maybe even 
instument locations (although this could be done by just chrooting ls if 
there is a security concern here)
What do you guys think?

As far as

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi all,
>
>Here goes, at least under my point of view 8)
>
>
>Preliminar specification for the LinuxSampler GUI application
>-------------------------------------------------------------
>
>According to current LSCP document draft (v.04), and the corresponding
>iblscp implementation, the following notes apply as proposed requirements
>for the primordial LinuxSampler GUI application.
>
>
>a)  Each sampler channel maps to one strip on the main GUI control panel,
>    whithin the main application window.
>
>b)  Sampler channel strips may be stacked on either a vertical (like a
>    mixing desk) or horizontal layout (like a studio rack).
>
>c)  Channel strips are added or removed at will.
>
>d)  Each sampler channel strip shall have the following GUI controls:
>
> 1. Engine        : string  <engine-name>   : option list.
>
> 2. Instrument    : string  <filename>      : button; fileopen dialog.
>
> 3. MIDI Type     : "alsa"                  : option list.
>
> 4. MIDI Port     : string  <midi-port>     : edit box.
>
> 5. MIDI Channel  : int     <midi-channel>  : option list.
>
> 6. Audio Type    : "alsa" | "jack"         : option list.
>
> 7. Audio Channel : int     <audio-channel> : edit spinbox.
>
> 8. Volume        : float   <volume>        : knob/slider; edit spinbox.
>
> 9. Voice Count   : int                     : display.
>
>10. Stream Usage  : int[]                   : display; chart.
>
>11. Reset         :                         : button.
>
>
>e)  The complete session state might be saved and loaded from the local
>    file system, as plain LSCP script documents.
>
>f)  The application setup options dialog include the linuxsampler server
>    hostname and port specification with option to auto-start the server
>locally (localhost), where the corresponding startup command-line may be
>user editable.
>
>g)  The main application window may follow the SDI model, with regular
>    menu, tool and status bars. The proposed initial menu hierarchy:
>
>    File
>
>        New             Start a new session state from scratch.
>        Open...         Load a session from an existing LSCP file.
>        Save            Save current state to a LSCP file.
>        Save As...      Save current state with an alternate name.
>        -               -
>        Quit            Quit application.
>
>    Edit
>
>        Add Channel     Add a new channel strip to current session.
>        Remove Channel  Remove selected channel strip from session.
>        -               -
>        Reset Channel   Reset currently selected sampler channel.
>
>    View
>
>        Show Menubar    Show/Hide the main window menubar.
>        Show Toolbar    Show/Hide the main window button toolbar.
>        Show Statusbar  Show/Hide the main window statusbar.
>        -               -
>        Show Messages   Show/Hide the messages log window (debug).
>        -               -
>        Options...      General options setup dialog.
>
>    Help
>
>        About...        Self-credits show off.
>
>
>Think this is enough, for the time being.
>
>Yet again, another important question remains, which deals with the
>"official" application name. My proposals goes to, in strict biased
>descending order of preference:
>
>    qsampler
>    qls
>    qlinuxsampler
>    lsgui
>    linuxsamplergui
>
>Of course, those "q" prefixes comes from my reliance to Qt :)
>
>So, make up your minds, ppl.
>
>Cheers.
>  
>

[Linuxsampler-devel] LinuxSampler GUI spec.

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

Hi all,

Here goes, at least under my point of view 8)


Preliminar specification for the LinuxSampler GUI application
-------------------------------------------------------------

According to current LSCP document draft (v.04), and the corresponding
iblscp implementation, the following notes apply as proposed requirements
for the primordial LinuxSampler GUI application.


a)  Each sampler channel maps to one strip on the main GUI control panel,
    whithin the main application window.

b)  Sampler channel strips may be stacked on either a vertical (like a
    mixing desk) or horizontal layout (like a studio rack).

c)  Channel strips are added or removed at will.

d)  Each sampler channel strip shall have the following GUI controls:

 1. Engine        : string  <engine-name>   : option list.

 2. Instrument    : string  <filename>      : button; fileopen dialog.

 3. MIDI Type     : "alsa"                  : option list.

 4. MIDI Port     : string  <midi-port>     : edit box.

 5. MIDI Channel  : int     <midi-channel>  : option list.

 6. Audio Type    : "alsa" | "jack"         : option list.

 7. Audio Channel : int     <audio-channel> : edit spinbox.

 8. Volume        : float   <volume>        : knob/slider; edit spinbox.

 9. Voice Count   : int                     : display.

10. Stream Usage  : int[]                   : display; chart.

11. Reset         :                         : button.


e)  The complete session state might be saved and loaded from the local
    file system, as plain LSCP script documents.

f)  The application setup options dialog include the linuxsampler server
    hostname and port specification with option to auto-start the server
locally (localhost), where the corresponding startup command-line may be
user editable.

g)  The main application window may follow the SDI model, with regular
    menu, tool and status bars. The proposed initial menu hierarchy:

    File

        New             Start a new session state from scratch.
        Open...         Load a session from an existing LSCP file.
        Save            Save current state to a LSCP file.
        Save As...      Save current state with an alternate name.
        -               -
        Quit            Quit application.

    Edit

        Add Channel     Add a new channel strip to current session.
        Remove Channel  Remove selected channel strip from session.
        -               -
        Reset Channel   Reset currently selected sampler channel.

    View

        Show Menubar    Show/Hide the main window menubar.
        Show Toolbar    Show/Hide the main window button toolbar.
        Show Statusbar  Show/Hide the main window statusbar.
        -               -
        Show Messages   Show/Hide the messages log window (debug).
        -               -
        Options...      General options setup dialog.

    Help

        About...        Self-credits show off.


Think this is enough, for the time being.

Yet again, another important question remains, which deals with the
"official" application name. My proposals goes to, in strict biased
descending order of preference:

    qsampler
    qls
    qlinuxsampler
    lsgui
    linuxsamplergui

Of course, those "q" prefixes comes from my reliance to Qt :)

So, make up your minds, ppl.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Latest CVS commit

[Emiliano G. <emi...@po...>]

mercoled=EC, 28 aprile 2004 alle 19:58:33, Christian Schoenebeck ha scrit=
to:
> > OK. This note also announces that, now that this important milestone =
has
> > been reached, I'll start coding for the GUI, ASAP :)

Hi, regarding this...

I'm not a coder and not a very skilled graphic person, but today I have
asked on an italian forum full of talented 3d graphic skilled guys if
someone would like to contribute some graphics to this project.

They use primarily blender, and I think they can produce something useful
in short time, but they need some input: a guy who is very active on the
forum asked about a pencil sketch of the main idea of the GUI, with (I
guess) faders, knobs, logos, and so on...

If this can be of any help, it would be fantastic :)

Some time ago (remember that I'm not a good designer) I made a blender
project with some knobs,sliders and leds:

http://www.emillo.net/download/mixer.png

and here the knob in various positions:

http://plugin.org.uk/graphics/Emiliano_Grilli/

That is rather ugly and unfinished, but imagine what a good designer can
do... just tell us what is needed :)

Best regards,


PS: sorry for my english
--=20
Emiliano Grilli
Linux user #209089=20
http://www.emillo.net

Re: [Linuxsampler-devel] Latest CVS commit

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

Es geschah am Montag, 26. April 2004 23:28 als Rui Nuno Capela schrieb:
> Guess what? I've just packaged liblscp as for "my" LSCP implementation C
> API, now focused mainly on the client-side interface (although my
> server-side code is still there, but just for example purposes, only).
>
> My humble offer is given that the liblscp package is now ready and
> self-contained, so that you can review it's automake stuff and check if it
> can be borrowed into liblinuxsampler. Of course, if you find anything
> severely wrong you may also blame me ;)
>
> The liblscp package is in pretty (ugly) auto/libtool canonical form, the
> least as I could get :) Doxygen and pkgconfig support is included.
>
> You can check it out from:
>
>     http://www.rncbc.org/ls/liblscp-0.1.5.tar.gz

Very good, I will look at it tomorrow.

> OK. This note also announces that, now that this important milestone has
> been reached, I'll start coding for the GUI, ASAP :)
>
> Hope you enjoy.

We will! :)

CU
Christian

Re: [Linuxsampler-devel] Latest CVS commit

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

Christian Schoenebeck wrote:
>
>* completely restructured source tree, I created a couple of
>  subdirectories and distributed the source files over them.
>  My idea was to create one big libtool library 'liblinuxsampler',
>  one libtool library libgig which is then just dynamically linked
>  by liblinuxsampler (because libgig is already packaged for some
>  systems) and the linuxsampler binary would just dynamically link
>  against liblinuxsampler, but I had some problems with setting
>  this up today, so if anybody's familiar with automake & libtool
>  help would be greatly appreciated!
>

Guess what? I've just packaged liblscp as for "my" LSCP implementation C
API, now focused mainly on the client-side interface (although my
server-side code is still there, but just for example purposes, only).

My humble offer is given that the liblscp package is now ready and
self-contained, so that you can review it's automake stuff and check if it
can be borrowed into liblinuxsampler. Of course, if you find anything
severely wrong you may also blame me ;)

The liblscp package is in pretty (ugly) auto/libtool canonical form, the
least as I could get :) Doxygen and pkgconfig support is included.

You can check it out from:

    http://www.rncbc.org/ls/liblscp-0.1.5.tar.gz

Installation from the untarred directory:

    make -f Makefile.cvs
    ./configure
    make
    make install

Or you can choose from a couple of RPMs which are also available from
http://www.rncbc.org/ls/ .

OK. This note also announces that, now that this important milestone has
been reached, I'll start coding for the GUI, ASAP :)

Hope you enjoy.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] Latest CVS commit

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

Hi!

I've been a bit silent but not idle ;)

First of: current version of LinuxSampler might be a bit unstable.
Therefore I created a tag "v0_1_0" and "singlechannel" for the old single
channel version. So if you have severe problems with current version of
LinuxSampler, you can checkout the old version by doing:

	cvs -z3 -d:pserver:sch...@cv...:/var/cvs/linuxsampler co -r v0_1_0 linuxsampler

If you encounter problems, let us know! We will try to fix them as fast as
possible. Sorry in advance for any inconvenience!

Now the changes:

	* completely restructured source tree, I created a couple of subdirectories
	  and distributed the source files over them. My idea was to create one big
	  libtool library 'liblinuxsampler', one libtool library libgig which is then
	  just dynamically linked by liblinuxsampler (because libgig is already
	  packaged for some systems) and the linuxsampler binary would just
	  dynamically link against liblinuxsampler, but I had some problems with
	  setting this up today, so if anybody's familiar with automake & libtool
	  help would be greatly appreciated!

	* implemented multi channel support, it's now possible to use multiple
	  sampler engines and thus multiple instruments simultaniously

	* implemented instrument manager, which controls sharing of instruments
	  between multiple sampler engines / sampler channels. The instrument manager
	  is responsible for loading instruments (and samples) in memory if needed by
	  a sampler engine and frees it from memory if not in use by any engine
	  anymore (I kept that as C++ template to reduce effort for further file
	  formats than Gigasampler)

	* created abstract classes 'AudioOutputDevice' and 'MidiInputDevice' for
	  convenient implementation of further audio output driver and MIDI input
	  driver for LinuxSampler. AudioOutputDevice is already designed in a way to
	  to easily extend it for efficient SMP (multi processor) and network cluster
	  support without dependency to the used audio system.

	* implemented following LSCP commands: 'SET CHANNEL MIDI INPUT TYPE',
	  'LOAD ENGINE', 'GET CHANNELS', 'ADD CHANNEL', 'REMOVE CHANNEL',
	  'SET CHANNEL AUDIO OUTPUT TYPE'

	* LSCP server is now launched by default

	* temporarily removed all command line options. You can use an LSCP script to
	  setup LinuxSampler though. I attached a short example script file. You can
	  send it to LinuxSampler by doing:  'cat start.lscp | nc -t localhost 8888'
	  which of course even works over network

CU
Christian

[Linuxsampler-devel] Free Organ GIG files 400MB and 200MB

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

more free samples to test LinuxSampler with so
that you can report if samples do sound incorrectly.
(some still do due to missing articulation implementation,
 velocity curve problems, eg wrong samples are triggered,
like the case of the PMI Boesendorfer)

http://www.orgona.org/e_disclaimer.php


Fonds 16' 8' 4' series DEMO.GIG (216.5 MB; uncompressed 439.2 MB)
NDB_REC - Voix Humaine 8'.GIG (109.4 MB; uncompressed 214.0 MB)

cheers,
Benno

http://www.linuxsampler.org




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

Re: [Linuxsampler-devel] Cross-platform

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

Es geschah am Freitag, 16. April 2004 15:37 als Tobias Erichsen schrieb:
> Hi everyone,

Hi!

> I haven't had much time lately for "private excursions" into
> programming, so the cross-platform integration of linuxsampler
> into the WIN32 environment was held back.
>
> And still it is not THAT much better now. But due to the fact,
> that I need to explore some fields of driver-development
> for my job, I have started developing a WIN32 kernel-
> driver for MIDI that is compliant to the upcoming IEEE P1639
> standard.  This standard is based on DMIDI which is a
> distributed MIDI implementation for Linux from Phil Kerr.
> See also: http://www.plus24.com/ieeep1639/index.php

Glad to hear that! I hope you don't give up.

> There is already a linux-client - but it seems there is no
> ALSA DMIDI/P1639 driver yet. Perhaps someone with
> more Linux-knowledge would do this part.

You should ask on the Linux Audio Developers mailing list or on the Alsa 
Developers list if anybody's working or interested in working on that. Many 
audio applications will benefit from a DMIDI client / driver.

> I hope to get an initial version of this driver ready during
> the next couple of weeks.  If linuxsampler would expose
> some kind of sysex-interface to the outside-world for
> configuration, I could even provide a GUI tool for config
> that would run over the network-midi (or possibly standard-
> midi if someone wishes to do so).

There will definitely be a sysex interface, but at least not in the next 
couple of weeks. At the moment we will only work on finishing the LS network 
protocol for the upcoming first official release of LinuxSampler.

> What do you guys think of this? I know this is not yet a
> full-blown integration also including the audio-streams,
> but it would be a start...

Yeah, it's a start. I hope we'll make progress on bringing LS also to Win and 
Mac. So keep going with your work!

CU
Christian

Re: [Linuxsampler-devel] API documentation & guidelines for GUI dev

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

Es geschah am Freitag, 16. April 2004 10:02 als Peter Roos schrieb:
> Can you maybe give any indication when there will be some stable API
> documentation for controlling LS from (say) a Windows box? I can imagine
> that besided a "dry" API reference list, there should also be some doc with
> guidelines for setting up a proper client framework that explains how to
> deal with establishing sessions, working with time-outs, graceful
> degradation, and so forth.
>
> Is that still far in the future? ;-) Or it is already possible to start
> experimenting with some barebones LS box and basic documentation?

Stable API? Probably never, but for the first official release of LS the API 
(and documentation) might become stable in one or two months. Currently I'm 
working on multi channel support, so there might be a couple of things that 
change in the LSCP API and beside the network protocol (and the liblscp 
library) there will also be a native C++ LS library (for local host only of 
course) very soon.

Meanwhile you can play a bit with the LS network protocol using a normal 
telnet connection and manually typing the control commands. You will see it's 
a quite simple and human readable protocol. If you have questions regarding 
the LSCP post it!

After the first release of LS we will then start (beside implementation of 
further sampler engines / formats) with all modularity features, on the fly 
recompilation of custom engines and profiling. As you might imagine this will 
mean a huge extension of the API, but it will be backward compatible I guess.

> Although I have background of many years in technical software engineering
> (I am also perception research psychologist), I am a bit hesistant by
> getting a Linux LS box up and running :-/

No one will force you. ;)

> I can't promise I can devote any serious UID attention on short term - my
> own business is not doing fine at the moment. But things can improve soon,
> and I can even think that a serious LS GUI for Windows might be commercial
> project for my Company.
>
> Or, is that actually something that you will be trying to avoid? Do you
> also want have the client GUI apps in the public domain?

Of course we would also like to see LS frontends to be free software, but as 
LinuxSampler and it's libraries are released under the GNU General Public 
License, commercial usage equals to any other software released under the 
GPL; means it is possible with the common restrictions given by the GPL. But 
that's more Marek's field, he is our lawyer, right Marek? ;)

CU
Christian

[Linuxsampler-devel] Cross-platform

[Tobias E. <t.e...@gm...>]

Hi everyone,

I haven't had much time lately for "private excursions" into
programming, so the cross-platform integration of linuxsampler
into the WIN32 environment was held back.

And still it is not THAT much better now. But due to the fact,
that I need to explore some fields of driver-development
for my job, I have started developing a WIN32 kernel-
driver for MIDI that is compliant to the upcoming IEEE P1639
standard.  This standard is based on DMIDI which is a
distributed MIDI implementation for Linux from Phil Kerr.
See also: http://www.plus24.com/ieeep1639/index.php

There is already a linux-client - but it seems there is no
ALSA DMIDI/P1639 driver yet. Perhaps someone with
more Linux-knowledge would do this part.

I hope to get an initial version of this driver ready during
the next couple of weeks.  If linuxsampler would expose
some kind of sysex-interface to the outside-world for
configuration, I could even provide a GUI tool for config
that would run over the network-midi (or possibly standard-
midi if someone wishes to do so).

What do you guys think of this? I know this is not yet a
full-blown integration also including the audio-streams,
but it would be a start...

Tobias 

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info

[Linuxsampler-devel] API documentation & guidelines for GUI dev

[Peter R. <pet...@de...>]

Hello guys,
 
I try to follow the discussions, but as a non-Linux man it's often too easy
to click them away.
 
Can you maybe give any indication when there will be some stable API
documentation for controlling LS from (say) a Windows box? I can imagine
that besided a "dry" API reference list, there should also be some doc with
guidelines for setting up a proper client framework that explains how to
deal with establishing sessions, working with time-outs, graceful
degradation, and so forth.
 
Is that still far in the future? ;-) Or it is already possible to start
experimenting with some barebones LS box and basic documentation?
 
Although I have background of many years in technical software engineering
(I am also perception research psychologist), I am a bit hesistant by
getting a Linux LS box up and running :-/
 
I can't promise I can devote any serious UID attention on short term - my
own business is not doing fine at the moment. But things can improve soon,
and I can even think that a serious LS GUI for Windows might be commercial
project for my Company.
 
Or, is that actually something that you will be trying to avoid? Do you also
want have the client GUI apps in the public domain?
 
Thanks for any reflections,
Regards,
 
Peter
 

Peter E. Roos
Senior IT and Media Consultant
Gsm +31 (0)655 755324
E-mail pet...@de... <mailto:pet...@de...> 
Icq # 227200164
Msn deltaworks_001 at hotmail.com
(not used for email)

Deltaworks BV 
Postal address: P.O. Box 512, 3720 AM Bilthoven, The Netherlands
Office address: Nieuwstraat 44 A, 3762 TR Soest, The Netherlands
phone +31 (0)35 588 5057
Website  <http://www.deltaworks.com/> www.deltaworks.com

Personal music website  <http://www.deltaworks.com/> www.PeterRoos.com 

 

Re: [Linuxsampler-devel] Multi Channel & Multi Engine Support

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

Es geschah am Donnerstag, 8. April 2004 03:08 als Rui Nuno Capela schrieb:
> Hi Christian,
>
> I've been away for some time but now I'm back to LS once again. Did you
> miss me? :)

Of couse, and guess what I'm also missing. ;)

> OK. I think I have almost ready my liblscp thing, the C API interface to
> LSCP. Check it out from http://www.rncbc.org/ls . Documention level is
> still low, but it's getting doxygen'ed :)
>
> The server side has been improved, now it can operate in either of two
> modes, in option: single-threaded multiplex (one thread serves all clients)
> or multi-threaded (one thread per client). Think that's what came out from
> our discussions one month ago, Chris?

My concerns were just not to create new threads whenever a new frontend 
connection is established, so using a thread pool instead. Anyway, it will be 
fine and it's good to hear from you again.

> 1) have a default configuration script file, with the proper LSCP commands
> to setup all the initial engines, channels and corresponding parameters
> (eg: "~/.lscprc" for local and/or "/etc/lscp.conf" for global default
> configuration);

I share Vladimir's opinion, that we should just move that task to the 
frontend, means no config files on server (=LS) side and LS will just be 
launched with no sampler channel at all. The frontend will have profiles / 
config files to send the appropriate LSCP commands to setup LS with the 
desired settings.

> See above. I think you can keep current command line spec, but adding a new
> option for an initial configuration lscprc file, but I'll suggest that the
> current --server option is made always active by default, so dropping it
> it's probably OK :)

Agreed, we launch the server by default.

> Now wandering... I was thinking about the GUI frontend in having the option
> to start the LS server itself, in case it finds that there's none currently
> active. Of course this only applies for the frontend being in the same
> local machine as the server (localhost).

Of course, this is an import feature. There will be liblinuxsampler which you 
can call natively by your frontend to launch a LS instance on the same host. 
The linuxsampler binary itself will also do the same; it just will call 
liblinuxsampler to actully launch LS.

Es geschah am Donnerstag, 8. April 2004 18:17 als Mark Knecht schrieb:
> Christian,
>    Hello. It's great to ear from you, and exciting to hear that work is
> taking place in this area. I'll give my 2 cents worth of input, for what
> it's worth. Overall, I'd like to preface the comments below that I'd
> most enjoy using LS if it presented itself as a GUI-based application to
> me. Maybe what the GUI looks like, or what the GUI does, could be
> defined in a config file somewhere, but when I type 'linuxsampler' at
> the command line I hope a GUI will present itself on my screen.

No, 'linuxsampler' will always just launch the 'server' means LS without a 
graphical frontend. 'qlinuxsampler' (or whatever Rui will name it) will 
launch the Qt frontend and that frontend will of course be able to launch LS 
in the background (if its on the same machine).

> 2) I sometimes go beyond 16 channels, so I use two MIDI interfaces for
> that. MIDI-A-0:15 going to one group of 16 gig files, and MIDI-B-0:15
> going to a second group of 16 gig files. I admit I don't use this often
> singe the version of GSt I own limits me to 96 voices. Since GSt is
> stereo, this is only 48 notes, so it's not hard to get there with just
> 16 MIDI channels. I hope that LS works well enough to allow me to go far
> beyond that, but so far there has been no opportunity to test the code
> for more than one MIDI channel at a time, so it's hard to know how well
> it will use the hardware resources at this time.

Actually there's still (too much ;) headroom to improve performance (e.g. we 
don't use SIMD optimizations yet). So don't take the current performance as 
the final norm, else you will be disappointed.

> 3) I never use 2 MIDI channels to drive a single gig file. I *think*
> that there is no overhead to just loading the same gig file into two GSt
> channels. That sampler can use the same loaded samples of a piano, for
> instance, on both channel 1 and channel 2 without loading extra audio
> samples into memory. It's no different than receiving two note-on events
> on MIDI channel 1 for middle C or receiving one on channel 1 and one on
> channel 2.
>
> 4) I do, at times, use a single MIDI channel to drive multiple gig
> files. This is an area that is of interest to many people using
> orchestral libraries. It would be really excellent to have some MIDI
> event mapping capabilities built within LinuxSampler to handle things
> like key splits, velocity curve remapping, note-on/note-off event
> mapping, etc. I lobbied on Linux-Audio-User in the last few days that
> this would be better placed in a single application outside of each
> synth, but I received not a single bit of agreement for the idea. The
> general Linux Audio community seems more comfortable that every synth
> implement their own set of features in this area. For that reason I'll
> work with you later, if you're interested, to define what some of these
> features could look like.

MIDI event preprocessing can be added later. But what do you mean with 
'note-on/note-off' event mapping?

> 5) As for the audio channel issue, it seems to me that there needs to be
> some sort of audio mixer similar to what's implemented in GSt. You'll
> need a small group of sub-mix buses for generalized reuse of common
> plugins, like reverb, or even just mixing of similar audio gigs, like
> multiple violin libraries on separate MIDI channels into a single violin
> audio stream. Something in LS needs to do do at least a minimal amount
> of audio mixing & mapping, in my opinion. I don't think that it's very
> user friendly to have every audio channel's output be a separate Jack
> output that has to get messed with outside of LS. I'm also not sure how
> well this will work when we look at remote VSTi implementations as
> viewed from a Windows environment, etc.

Sampler channel x, sampler channel y, sampler z, ... all mixed together to one 
VSTi (/Jack/CoreAudio,...) output 'channel' won't be a problem as long as we 
only allow one audio output per sampler channel, this constrain is 
unavoidable due to the fact that VSTi is callback based. Plugin support will 
probably follow later.

>    At this point I've likely overstayed my welcome on your CRT, so I'll
> sign off for now. As always, I'm around.

WTF is CRT?

Es geschah am Freitag, 9. April 2004 02:50 als Vladimir Senkov schrieb:
> Command line options are perhaps needed for stuff that MUST happen during
> bootup of the backend. For example, if we wanted to limit how much memory
> it can allocate and lock that perhaps should be configured via the command
> line option to give administrators of samplers and perhaps even developers
> who will develop and sell "hardware" samplers based on LS some control over
> the resources of the system.

Agreed. So I would propose that we just drop all channel specific command line 
parameters (like loading an instrument, overriding audio output system, MIDI 
input system) and just keep global parameters.

> If there is ever a need, we could create an autogenerated CLI interface
> from the same parser as the server uses. Complete with comand completion,
> "?" and all that good stuff. I'm trying to create a router again?! No. NO
> CLI! :)

I like that idea of a LSCP console with auto completion!

CU
Christian

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

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

Mark,

I'm not suggesting that everything MUST be done on the same PC all the 
time :)
Although i'd like to think that eventually linux will have enough apps 
so you could do it (by just adding another harddrive for "output").
So, the point is . . . it's a functional problem, not performance. I 
fully agree with your "functional" part of the argumentation but on 
performance i'm not so sure.

I personally would like to see LS as modular as possible and as easy to 
use with other tools as possible.
I was hoping that mixing could be put outside the sampler itself and 
something like jack could be used to interface into that. But maybe this 
is not efficient enough and there needs to be more "mixing points". I 
simply don't know.

BTW, if LS supported audio over Ethernet would that help (in terms of 
reducing the number of cables and interfaces)?

Careful with those eggs . . .
I've just seen on TV some kids were looking for eggs and found two 
loaded guns instead :)

Regards,
Vladimir.

Mark Knecht wrote:

>On Sun, 2004-04-11 at 10:49, Vladimir Senkov wrote:
>  
>
>>Mark,
>>
>><SNIP>
>>    
>>
>
>  
>
>>For instance if 
>>you have a hardware raid on 64bit wide PCI running at 133Mhz with 
>>several good SCSI drives 
>>    
>>
><SNIP>
>  
>
>>Regards,
>>Vladimir.
>>
>>Mark Knecht wrote:
>>
>>    
>>
><SNIP>
>  
>
>>you'll need an audio mixer of
>>    
>>
>>>some type as most people won't have enough hardware to get all of that
>>>audio to the hard disk recorder as separate channels.
>>>      
>>>
><SNIP>
>
>You can certainly buy hardware to meet whatever set of criteria you want
>to shoot for.
>
>My point was that most people won't have that available, nor do they
>want to. I'll state straight out that I won't be using a Linux-based DAW
>for the foreseeable future. I'm far more likely to dump $50K into a Pro
>Tools HD-Accel system than attempt to run a Linux recorder and a sampler
>on the same box. For this reason, since Pro Tools and LS by definition
>do not even run on the same OS, to me the point is moot.
>
>Really the question is whether you want the mixer in the app, or require
>people to hook up 32 audio outputs using Jack and then do it all by hand
>somehow. I think that's not a good use of my time, and I think that
>almost no GSt user coming from Windows to try this out would think so
>either, but I'm not arguing that LS should be some hard coded monster
>GUI that wouldn't support that model. If others want it that way I hope
>the code base supports it.
>
>Anyway, I was fairly careful in my original response to use terms like
>'How LS presents itself'. It's not of much interest to me as a user
>what's under the hood. If it's easy to use, stable and does what I need,
>then I'll us it. If not, then it's unlikely that I or many other Windows
>users would invest huge amounts of time.
>
>Looking for eggs in the back yard,
>Mark
>
>  
>

Re: [Linuxsampler-devel] LS future, multiengine , audio channels

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

On Sun, 2004-04-11 at 10:49, Vladimir Senkov wrote:
> Mark,
> 
> <SNIP>

> For instance if 
> you have a hardware raid on 64bit wide PCI running at 133Mhz with 
> several good SCSI drives 
<SNIP>
> 
> Regards,
> Vladimir.
> 
> Mark Knecht wrote:
> 
<SNIP>
> you'll need an audio mixer of
> >some type as most people won't have enough hardware to get all of that
> >audio to the hard disk recorder as separate channels.
<SNIP>

You can certainly buy hardware to meet whatever set of criteria you want
to shoot for.

My point was that most people won't have that available, nor do they
want to. I'll state straight out that I won't be using a Linux-based DAW
for the foreseeable future. I'm far more likely to dump $50K into a Pro
Tools HD-Accel system than attempt to run a Linux recorder and a sampler
on the same box. For this reason, since Pro Tools and LS by definition
do not even run on the same OS, to me the point is moot.

Really the question is whether you want the mixer in the app, or require
people to hook up 32 audio outputs using Jack and then do it all by hand
somehow. I think that's not a good use of my time, and I think that
almost no GSt user coming from Windows to try this out would think so
either, but I'm not arguing that LS should be some hard coded monster
GUI that wouldn't support that model. If others want it that way I hope
the code base supports it.

Anyway, I was fairly careful in my original response to use terms like
'How LS presents itself'. It's not of much interest to me as a user
what's under the hood. If it's easy to use, stable and does what I need,
then I'll us it. If not, then it's unlikely that I or many other Windows
users would invest huge amounts of time.

Looking for eggs in the back yard,
Mark

[Linuxsampler-devel] bug fix

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

Hi all,

fyi . . .
I've submitted a small fix that should take care of some crashes we've 
seen when requested stream is not available in time.

While i believe this is a low risk change, please let me know if 
something stops working :)

Regards,
Vladimir.