Running LinuxSampler/QSampler against JACK, when I open the "Devices" dialog and click on the "Audio Devices" item on the left side, the widgets on the right side allow to modify the JACK sample rate although this doesn't make sense (as far as I know) when jackd is already running. In fact, if I modify that setting and create a new JACK device, it receives the standard jackd sample rate. I suggest that this item be disabled ("ghosted") in the GUI when running against JACK.
Yes, makes sense. Since the JACK API currently does not allow to change the sample rate after jackd has been launched. Surprisingly though, since the sample rate can be adjusted during runtime of jackd.
This issue probably has to be addressed in the sampler's network protocol first. Currently there is only one parameter information field related to this issue, called "FIX": http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#GET%20AUDIO_OUTPUT_DRIVER_PARAMETER INFO If a parameter is FIX=false it means that parameter can be altered at any time by the user. And FIX=true currently means a user chosen value for this parameter may be given at device creation (driver instantiation) time, however may not be altered by the user after the device was created. But for this particular issue here, we would need to address a third case: a parameter which is always read-only, which can neither be given at device creation time, nor altered at runtime afterwards. I am currently unresolved how to address this in best way. I currently see two options: 1) Adding a new parameter info field to LSCP like "READ_ONLY". READ_ONLY=true would then mean that the given parameter is just for informational purposes, but may not be given or altered at any time by the user. However having "FIX" and "READ_ONLY" would make this part of the protocol a bit unclean and unintuitive. or alternative: 2) Not exposing the existence of those particular driver parameters (via LSCP) before the device has been created. So in this case, the SAMPLERATE parameter would for example be shown to the frontend (i.e. QSampler) by the sampler *only* after the JACK device has been created. Disadvantage would be that i.e. QSampler would not know anything about the existence of i.e. parameter SAMPLERATE before it created a JACK device. Could that bad for some kind of parameter now or in future? I am not sure ... For example a user might have 2 sound cards in his box, one with hardware given 44.1kHz and the other one with 96kHz. At the moment, with the current protocol (i.e. with driver "ALSA") one could show him that particular difference of the two sound cards before selecting one of them for usage in the sampler.