jsynthlib-devel

[Jsynthlib-devel] Re: two bugs

[Brian <br...@ov...>]

federico wrote:

> 1) the MKS7 driver i just developed, controls only one timbral part.
> to get control of all three parts (chord,melody,bass), i have to 
> create 3 driver instances, with 3 different IDs and MIDICHANs.
>
> so i created patches with ID 'MKS-7-B','MKS-7-M','MKS-7' (for the main 
> part).
> but when i save patchlib, close and reopen it, all sounds get remapped 
> to the main id ('MKS-7').
>
> i guess this ID is not stored in the file, so gets matched by the 
> sysex_id of the driver...
> or otherwise please enlighten me.



JSynthLib does not play nice with having more of one of the same 
synthesizer. Origionally this did not work at all. Now it works, but
not in the best way possible. Basically you are correct. When you open a 
patchlib everything is matched by the sysex_id of the driver,
so the first driver loaded gets assigned all the patches. To change 
which driver gets the patch, you have to use "Reassign" in the Patch
Menu. This will assign the patch to a different instance of the synth. 
However, you would have to do this each time you load a library.

As for your specific case its a little differnt, you don't have three 
different synths, but one synth with different midi channels that
you want to use. What is the ID field you are talking about that 
contains "MKS-7-B", etc. Is this a part of the actual sysex for the MK-7?
Is there someway that it is possible to tell which part 
(chord,melody,bass) a patch belongs in based on looking at the patch? If 
so,
maybe you could have the MK7 Device have three drivers each being 
identical except having a sysex_id that will only match the
patches which should be for that part? That would be the optimal way to 
do it.

Brian

Re: [Jsynthlib-devel] Re: two bugs

[federico <xa...@in...>]

Brian wrote:

> JSynthLib does not play nice with having more of one of the same 
> synthesizer.

d'oh! :-O

> Menu. This will assign the patch to a different instance of the synth. 
> However, you would have to do this each time you load a library.

yes, it's terrible! :-)

> As for your specific case its a little differnt, you don't have three 
> different synths, but one synth with different midi channels that
> you want to use. What is the ID field you are talking about that 
> contains "MKS-7-B", etc. Is this a part of the actual sysex for the MK-7?

no. it is the Synth ID i given to the three instances of driver.
the midi channel and the device id are set to the mks's receiving midi 
channel

> Is there someway that it is possible to tell which part 
> (chord,melody,bass) a patch belongs in based on looking at the patch?

as i said, dev_id and midi_ch are set to the same number, which is the 
midi channel.
here is the MKS7 sysex header (one byte per line):

F0
<id:roland>
<model:mks7>
<opcode:param_change/tone_change>
<midi channel>
<data ...>
F7

when you turn on the device, melody is channel 1, bass is channel 2, 
chord is channel 3 (however you change them with a button) and there 
isn't other method to distinguish parts.

> If so,
> maybe you could have the MK7 Device have three drivers each being 
> identical except having a sysex_id that will only match the
> patches which should be for that part? That would be the optimal way 
> to do it.
>
uhm i think it is not possible (see above)

i thought another approach: make three tabs, one for part. but this 
would drive into a  DOUBLE problem: conceptually doesn't exists anymore 
the patch, but only the BANK concept, since the driver controls an 
entire bank (bank on synthesizer, not a jsl's bank); you can't specify 
three midichannels in the driver's settings.
so i decided to abandone this way.

the really optimal way would be make possible to have many driver 
instances (think the surreal situation in which you have 3 synthesizers, 
same brand, same model ;D)

maybe add a column to the patchlib database would solve the prbl, i.e. a 
field to specify midi channel for a patch (uhm, this may be heavily 
redundant).
otherwise is it possible access FIELD1/FIELD2 from the editor/driver?



about the midi problem, i quote here your message:

> What platform are you using? (Operating System / Java Version / Midi 
> Provider?
>
Linux 2.6

java version "1.4.2-01"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)

Advanced Linux Sound Architecture Driver Version 1.0.7.
Compiled on Mar  5 2005 for kernel 2.6.10-gentoo-r6.

i access midi through the /dev/snd/midi* and /dev/midi* devices.


-- 
Federico

Re: [Jsynthlib-devel] Re: two bugs

[Brian <br...@ov...>]

>
>
>>
>
> as i said, dev_id and midi_ch are set to the same number, which is the 
> midi channel.
> here is the MKS7 sysex header (one byte per line):
>
> F0
> <id:roland>
> <model:mks7>
> <opcode:param_change/tone_change>
> <midi channel>
> <data ...>
> F7
>

Is the <midi channel>  different for each part? If so and <opcode> is a 
fixed size, you could write a SysexID that would only match the correct 
patches that want on that channel.

Basically you would have two different Devices, one for the Juno 106 
which would contain one SingleDriver w/ the <midi channel> always set to 
whatever the setting in preferences was.

You would have one device for the Mk& which would contain three copies 
of the single driver which would all be the same except rather than just 
all using the setting from preference, they
could either be set via their configuration screen, or just use the 
setting in preferences for the first, preferences +1 for second and 
preferences +2 for third.

This might be a good short term solution.

> when you turn on the device, melody is channel 1, bass is channel 2, 
> chord is channel 3 (however you change them with a button) and there 
> isn't other method to distinguish parts.
>
> i thought another approach: make three tabs, one for part. but this 
> would drive into a  DOUBLE problem: conceptually doesn't exists 
> anymore the patch, but only the BANK concept, since the driver 
> controls an entire bank (bank on synthesizer, not a jsl's bank); you 
> can't specify three midichannels in the driver's settings.
> so i decided to abandone this way.
>
> the really optimal way would be make possible to have many driver 
> instances (think the surreal situation in which you have 3 
> synthesizers, same brand, same model ;D) 


It is possible to have many driver instances, the issue is that 
.patchlib files are setup independant, that is you could write one on 
your computer, mail it to me and I should be able to open it. Even if I 
have different synths than you, if
one of mine is compatable with yours it should work. So if you were to 
create an MKS7 patch, save it, uninstall the Mks7 driver, install a Juno 
106 driver, and reopen the patch, JSynthLib would consider it a Juno106 
patch, then if you also
installed an MkS7 driver, you could reassign it and use it with either.

We need to figure out an interface that would allow multiple synths of 
the same type to work better than they do now without hardcoding midi 
channels or ports or anything, since these are setup dependant and could 
be changed when
the library is re-opened.

>
>
> maybe add a column to the patchlib database would solve the prbl, i.e. 
> a field to specify midi channel for a patch (uhm, this may be heavily 
> redundant).
> otherwise is it possible access FIELD1/FIELD2 from the editor/driver?

Adding a midi channel would make it non-portable between setups. Editors 
can not see field1/field2 because they only exist for Libraries. By the 
time an editor sees a patch, that patch could be in a library, or it 
could be in a scene, or a bank, neither
of which have a field1/field2 assigned to each patch.

As for the long term solution to the multiple device problem, I'm open 
to suggestions. Just to brain storm, how about this:

PatchLibs  /SceneLibs could store some sort of driverID unique to your 
setup with each patch that could be either set or blank. If it is set, 
that driver is used, if it is blank or if the driverID does not exist, 
JSynthLib sets the driver using
the SysexID. The driverID would be kind of a cache for the results of 
the patch assign process which is also modified by the "Reassign" command.

Brian




>
>
>
> about the midi problem, i quote here your message:
>
>> What platform are you using? (Operating System / Java Version / Midi 
>> Provider?
>>
> Linux 2.6
>
> java version "1.4.2-01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 
> Blackdown-1.4.2-01)
> Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)
>
> Advanced Linux Sound Architecture Driver Version 1.0.7.
> Compiled on Mar  5 2005 for kernel 2.6.10-gentoo-r6.
>
> i access midi through the /dev/snd/midi* and /dev/midi* devices.
>
>

Re: [Jsynthlib-devel] Re: two bugs

[federico <xa...@in...>]

>>
>> F0
>> <id:roland>
>> <model:mks7>
>> <opcode:param_change/tone_change>
>> <midi channel>
>> <data ...>
>> F7
>>
>
> Is the <midi channel>  different for each part? 

yes

> If so and <opcode> is a fixed size, you could write a SysexID that 
> would only match the correct patches that want on that channel.
>
note: the channel should remain user-configurable.
forcing to channels 1, 2 and 3, make the patch not-portable (by the 
driver implementation)

> We need to figure out an interface that would allow multiple synths of 
> the same type to work better than they do now without hardcoding midi 
> channels or ports or anything, since these are setup dependant and 
> could be changed when
> the library is re-opened.

possible solution: add a column (a field) in the patchlib db to force 
the SynthID value to match that specified in the driver settings.

if this field is empty, then the SynthID is guessed from sysex header.
if this field is set, try to match it with SynthID in the driver's 
preferences.
if the match fails, fall back to automatic SynthID guessing.

> PatchLibs  /SceneLibs could store some sort of driverID unique to your 
> setup with each patch that could be either set or blank. If it is set, 
> that driver is used, if it is blank or if the driverID does not exist, 
> JSynthLib sets the driver using
> the SysexID.

i guess we are talking about the same thing :-D

> The driverID would be kind of a cache for the results of the patch 
> assign process which is also modified by the "Reassign" command.

i think this is the better solution.
let's wait for other's opinions

-- 
Federico