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