Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <chr...@ep...> - 2004-01-11 17:15:20
|
Changes: - There was still this annoying problem that some .gig instruments were detuned. I hope I have fixed this now. If you have still a .gig that sounds detuned, please let me know! - As promised I finished an initial version of the amplitude envelope generator (EG1), so far only a simple ASR one. Extending it to a PADSDR one (as used in Gigasampler) is quite easy. If anybody likes to do this task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir perhaps? The EG has a minimum release time, in case the release time given by the gig file is 0s for example. Without this min. release time we would again have the click problem in case of zero release times when the voice will be released before it's sample end. This min. release time is defined in line 32 of src/eg_vca.h and there's another #define which sets the bottom value limit of the Exp curve, thus also defines the end of the EG curve in general. These two #define values still have to be adjusted to good values CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-03-10 22:42:54
|
Changes: * src/eg_vca.cpp: added following transitions to the envelope generator: 'Attack_Hold' -> 'Release', 'Decay_1' -> 'Release' in case of a release event. Here the new state chart diagram for EG1: http://www.linuxsampler.org/doc/engines/gig/eg1.pdf http://www.linuxsampler.org/doc/engines/gig/eg1.scd The latter is as always the TCM source file of the diagram. * EG1 parameters 'Attack Time', 'Release Time' and 'Sustain Time' are now controllable by a MIDI controller defined in the .gig file. The amount of influence the controller can cause has still to be adjusted to the orginal behavior of Gigasampler though. * src/voice.cpp: fixed bug in pitch calculation which caused new triggered voices to be played back without honoring the current pitch bend value. The power of paranthesis... ;) (only one single paranthesis was missing) CU Christian |
|
From: Mark K. <mar...@co...> - 2004-03-11 01:16:41
|
Christian, I'm not sure if you saw an earlier email I sent to you. I never saw a reply so maybe it didn't get there or I forgot to send it? Anyway, I was looking at the GSt help files and they showed decay_1 as an exponential decay and not linear as is shown in your eg1.pdf file below. Maybe you've already changed it to exponential in LS and the diagram just didn't get updated? Or possibly you have a reason to leave it linear and be different from GSt? Either way is OK with me as long as you have a reason you feel is appropriate. Anyway, I'm just following up as this seemed to be the only difference I found between the two implementation's documentation. With best regards, Mark On Wed, 2004-03-10 at 14:23, Christian Schoenebeck wrote: > Changes: > > * src/eg_vca.cpp: added following transitions to the envelope > generator: 'Attack_Hold' -> 'Release', 'Decay_1' -> 'Release' in > case of a release event. Here the new state chart diagram for EG1: > > http://www.linuxsampler.org/doc/engines/gig/eg1.pdf > http://www.linuxsampler.org/doc/engines/gig/eg1.scd > > The latter is as always the TCM source file of the diagram. > > * EG1 parameters 'Attack Time', 'Release Time' and 'Sustain Time' > are now controllable by a MIDI controller defined in the .gig > file. The amount of influence the controller can cause has still > to be adjusted to the orginal behavior of Gigasampler though. > > * src/voice.cpp: fixed bug in pitch calculation which caused new > triggered voices to be played back without honoring the current > pitch bend value. The power of paranthesis... ;) (only one single > paranthesis was missing) > > CU > Christian > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <chr...@ep...> - 2004-03-11 02:11:20
|
Es geschah am Thursday 11 March 2004 01:58 als Mark Knecht schrieb: > Christian, > I'm not sure if you saw an earlier email I sent to you. I never saw a > reply so maybe it didn't get there or I forgot to send it? > > Anyway, I was looking at the GSt help files and they showed decay_1 > as an exponential decay and not linear as is shown in your eg1.pdf file > below. Maybe you've already changed it to exponential in LS and the > diagram just didn't get updated? Or possibly you have a reason to leave > it linear and be different from GSt? I received it and haven't forgotten. I just felt that it wouldn't be that important for the moment, but I will fix it to exp. with the next commit. CU Christian |
|
From: Mark K. <mar...@co...> - 2004-03-11 02:17:10
|
On Wed, 2004-03-10 at 17:51, Christian Schoenebeck wrote: > Es geschah am Thursday 11 March 2004 01:58 als Mark Knecht schrieb: > > Christian, > > I'm not sure if you saw an earlier email I sent to you. I never saw a > > reply so maybe it didn't get there or I forgot to send it? > > > > Anyway, I was looking at the GSt help files and they showed decay_1 > > as an exponential decay and not linear as is shown in your eg1.pdf file > > below. Maybe you've already changed it to exponential in LS and the > > diagram just didn't get updated? Or possibly you have a reason to leave > > it linear and be different from GSt? > > I received it and haven't forgotten. I just felt that it wouldn't be that > important for the moment, but I will fix it to exp. with the next commit. > Works for me! Take care, Mark |
|
From: Christian S. <chr...@ep...> - 2004-03-30 13:48:30
|
Changes: * added Envelope Generator 2 and 3 (filter cutoff EG and pitch EG) for accurate .gig playback * fixed accuracy of pitch calculation * changed filter cutoff range to 100Hz..10kHz with exponential curve, this value range can also be adjusted on compile time by setting FILTER_CUTOFF_MIN and FILTER_CUTOFF_MAX in src/voice.h to desired frequencies * src/lfo.h: lfo is now generalized to a C++ template, which will be useful especially when we implement further engines Note: filter code is still disabled by default, you have to explicitly enable it in src/voice.h by setting ENABLE_FILTER to 1, otherwise filter code will be ignored at compile time. CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-04-26 18:01:09
Attachments:
start.lscp
|
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 |
|
From: Rui N. C. <rn...@rn...> - 2004-04-26 21:30:49
|
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...
|
|
From: Christian S. <chr...@ep...> - 2004-04-28 18:03:37
|
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 |
|
From: Emiliano G. <emi...@po...> - 2004-04-28 19:42:34
|
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 |
|
From: Rui N. C. <rn...@rn...> - 2004-04-29 11:00:45
|
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...
|
|
From: Vladimir S. <ha...@so...> - 2004-04-29 13:03:29
|
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. > > |
|
From: Christian S. <chr...@ep...> - 2004-04-29 16:15:54
|
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 |
|
From: Rui N. C. <rn...@rn...> - 2004-04-29 16:45:33
|
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... |
|
From: Mark K. <mar...@co...> - 2004-04-30 00:42:55
|
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. |
|
From: Rui N. C. <rn...@rn...> - 2004-04-30 08:38:54
|
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... |
|
From: Christian S. <chr...@ep...> - 2004-05-02 18:01:31
|
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 |
|
From: Rui N. C. <rn...@rn...> - 2004-06-26 14:45:59
|
Hi, Just a lil'bumpin' :) qsampler-0.0.2.93: * Prepared for client event protocol interface, via thread-safe QCustomEvent callback posting, on attempt to comply with draft-protocol v.11. liblscp-0.1.9.102: * Major changes to server event protocol interface on attempt to comply with draft-protocol v.11. This is to say that liblscp already implements the new event notification protocol, via an alternate but ordinary TCP socket connection, on both client and server side. Thus officially dropping the now obsoleted UDP event stream, as of original LSCP specification. However, current linuxsampler server is not ready for this yet. Multi-connection/client support is a milestone requirement not yet met by current linuxsampler server implementation. As ever, it's work in progress... Enjoy, -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-06-27 13:56:24
|
qsampler 0.0.2.95: * Avoid channel voice/stream usage auto-update while intrument loading is erroneous or incomplete. Bye. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-05-04 18:59:24
|
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 |
|
From: Christian S. <chr...@ep...> - 2004-05-06 20:20:35
|
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
|
|
From: Christian S. <chr...@ep...> - 2004-06-14 19:59:30
|
Hi! First off my latest commit may break things a bit, so I uploaded a CVS snapshot tarball before: http://www.linuxsampler.org/downloads.html Rui, I propose you also upload a snapshot of a qsampler version which fits the best to that LS version, so that users have a working environment while we implement the new network protocol draft and deal with the transition due to this. Now the changes: * src/common: added template class 'optional<>' which can be used e.g. as return type whenever a value might be returned, but don't has to; this template class pretty much acts like a pointer of the given type, but is much more safer than a simple pointer * src/audiodriver: added static class AudioDeviceFactory to create audio devices at runtime by using a string and to obtain driver informations of drivers at runtime, driver classes should simply use the macro REGISTER_AUDIO_OUTPUT_DRIVER(DriverName,DriverClass) in their cpp file to register the driver to LinuxSampler (no changes needed anymore in the LS code to add a new audio output driver) * src/drivers: added classes to dynamically manage driver parameters; there are two different kinds of parameters: parameters which are need to create a new device (DeviceCreationParameterX) used to e.g. create an audio output device or a MIDI input device and parameters which are only available at runtime, means when a device is already created (DeviceRuntimeParameterX) which will be e.g. used as audio channel parameters and MIDI port parameters * src/linuxsampler.cpp: all registered audio output drivers will be shown on the console on startup * src/network: implemented configuration of audio output devices via LSCP Vladimir, sorry I did not have the time to test it, so it maybe buggy as hell. But I hope the course is clear with the stuff I commited. MIDI device configuration can simply be done the same, so you just have to duplicate the used technics for MIDI device configuration. This will be my last commit (major commit at least) for the next four weeks or so, once again exams time... Hope you guys won't let development of LS stall in the meantime !!! CU Christian P.S. Maybe you even get Benno to move his ass ! |
|
From: Christian S. <chr...@ep...> - 2004-06-14 22:17:47
|
Es geschah am Montag, 14. Juni 2004 23:35 als Rui Nuno Capela schrieb: > Hi Christian, > > > First off my latest commit may break things a bit, so I uploaded a CVS > > snapshot tarball before: > > > > http://www.linuxsampler.org/downloads.html > > I've noticed you tagged the cvs snapshot tarball with something like > version 0.2.0. However the AM_INIT_AUTOMAKE on top configure.in still > references a 0.1 version. The later is where I pick the linuxsampler Feel free to fix it. Actually 0.1 was meant for the old single channel version (there's also a tag in CVS for this) and 0.2 was meant since then for the multi channel version of LS. > package version tag for my own snapshots in http://www.rncbc.org/ls/. Well, it would make more sense to place it on the LS website, don't you think? I don't like the situation to have various resources, this especially accounts to the protocol draft. There should only be one reource for the protocol doc otherwise we end in chaos. > > Rui, I propose you also upload a snapshot of a qsampler version which > > fits the best to that LS version, so that users have a working > > environment while we implement the new network protocol draft and deal > > with the transition due to this. > > No problem. > > Both qsampler 0.0.1 and liblscp 0.1.9.98 alpha-releases are fundamentally > working with the latest cvs20040613 snapshot. The same is valid with > current qsampler and liblscp CVS HEAD. If I'm not terribly mistaken, those > are even supposed to work on any forthcoming linuxsampler server changes, > as far as of latest LSCP draft specification (v.08). So don't worry. Current LS version from CVS HEAD is quite unstable and the protocol transition will bring situations where GUI and engine won't work together, so that's why I made the snapshot from yesterdays version. > Nevertheless, I'm planning to package next alpha-releases of qsampler > 0.0.2 and liblscp 0.1.9.99, starting tomorrow, based on current CVS HEAD > of course. > > Just to have a baseline, just before your "leave" ;) Fine. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-06-14 23:11:15
|
Christian, > >> [...] my own snapshots in http://www.rncbc.org/ls/. > > Well, it would make more sense to place it on the LS website, don't you > think? It's planned to be as soon as I get the qsampler and liblscp web pages into ls.org, as benno suggested while ago. I'm still preparing some php scripts or whatever to ease the pain ;) > I don't like the situation to have various resources, this especially > accounts to the protocol draft. There should only be one reource for the > protocol doc otherwise we end in chaos. > Already off :) Bye. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-06-15 02:37:55
|
Hi All, As Christian pointed out, things may be unstable for the time being. Indeed they are. In particular, base classes from driver direcrory are calling pure virtuals implemented in a derived classes (in audiodriver directory). I need to find an elegant way to get around this without breaking too much of the beauty that Christian architected. If any of you already have this fixed or are planning to jump on it please let me know to avoid duplicatoin. In the mean time, i'll put that on my TODO list. I should be able to get to this on the weekend. Nothing to worry about, just small issues here and there . . . good news is that there is whole bunch of new code and functionality there. I'm impressed! I think this is a giant step forward and with steps like that we'll see things improve very soon. Regards, Vladimir. |
Thanks for helping keep SourceForge clean.
X