Xpantastic!

I'm trying to understand the calculations that the single patch browser (included with Xplorer) ueses.

Looking at XpanderSysEx.h

// Single patch data sysex length is 399 bytes
// 6 bytes for sysex intro: F0 10 02....
static const int PRG_DUMP_DATA_FOLLOWS_INTRO_LENGTH = 6;
// 188 double bytes data for the values and 8 double bytes for the patch name
static const int PATCHNAME_LENGTH = 8;
static const int OBWORDS_DATA_LENGTH = 196 - PATCHNAME_LENGTH;
// 6 (intro) +196*2 (data+name) +1 (EOX) = 399

I understand that PRG_DUMP_DATA_FOLLOWS_INTRO_LENGTH is for the Sysex cmd overhead to request a single patch, however, I don't understand why he subtracts the patchname length from 196, when the patch name is part of each single patch.

196 & 2 + 8 = 399 bytes, which is correct

What am I missing?

Has anyone here attempted to disassemble the XPander or Matrix 12 ROMS?

If so, where is the dissembled source code at?

If not, what would you recommend using getting the ROM bin files that are separated

into even & odd addresses, into 1 contiguous file? I don't want to goof that up and make the job more difficult.

Thanks

Tony

Hi Tony, if you're willing to share, I'm curious to know what your plans are for the code?

PeWe Wrote:

>>"So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
>> I dunno if that´s doable via software at all, but it would be great if it were."

Hi PeWe,

This is what I am talking about. Permanently assigning some parameters to midi CC's like many current synths are capable of doing. Yes it would take

a considerable amount of understanding of the firmware, but it should be possible if enough room could be found in the ROMS. If not just have to use the slower

sysex method.

Another possibility:

I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. Using this technique it may be possible to allow more room

for added features. But I have not fully investigated this yet.

Sent you a PM

Best Karl

On Wednesday, June 13, 2018 10:12 PM, "PeWe ha-pewe@... [xpantastic]" <xpantastic@yahoogroups.com> wrote:

Hi Karl !

A bit O.T. but ...

Assigning MIDI CCs to Xpander-parameters like VCF cutoff and MIDI volume works on my Xpander uising the MIDI Controls page.

The limitation are the modulation busses,- pedals #1 & #2 and levers #1 & #2,- which isn´t enough, especially vs. the count of modulation destinations in the mod-matrix.
So, when there were a chance maxing out modulation busses in the sense of mod-sources, that would be most excellent.

There´s a bug in Multipatch-Mode when changing multi-patches via MIDI PrgCh. while MIDI CC#07 is assigned to "pedal #2" as a source and a value is being received.
The volume drops to zero then and it needs another MIDI CC#07=127 command to get some noise back from the synth.

I´m pretty sure it´s a bug because "lever #2 and "pedal #2" are "universal" (global) controllers while lever and pedal #1 work individual for each voice.
So, in Multipatch Mode, MIDI CC#07 should be the master volume controller which should work when sending a program change and volume offset command,- but it doesn´t because there´s no guarantee, the volume command arrives after the program change in exact sequential order when being transmitted from p.ex. a MIDI processor/matrix switcher or masterkeyboard.
A sequencer might handle that different compared to the devices mentioned above though.

In addition to the "master volume" functionality in "Multipatch-Mode", individual / relative volume control (not overriding MIDI CC#07 value !) for each voice should work using MIDI CC#11 together w/ MIDI CC#07 and w/o dropping overall volume to zero.
But even when we can get rid of the bug mentioned above, in Multipatch-Mode using MIDI CC#07 and MIDI CC#11 simultaneously eats up both pedals as modulation sources and makes it impossible using MIDI CC#04 for filter cutoff, may it be per voice or global,- WHEN the mod wheel is in use for vibrato p.ex..

So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
I dunno if that´s doable via software at all, but it would be great if it were.

Anyway,- now some private stuff and because it´s the occasion to send some lines ...

I received and still do receive all your emails, but when I reply, ALL the emails I send to shire03@... come back to me as a mailer demon after exactly 4 (FOUR !!!) days.
I regret and have no idea what causes that behaviour, but we should try to find another way for private communication I think.
Maybe PMs @ Keybd Corner ... (???) ... what do you think ?
Please reply to my private email addy 1st.
When you agree, you might post something over there,- I´ll recognize and will jump in via PM.
Let me know please.

thx for reading

:-)

PeWe


Am 14.06.2018 um 00:02 schrieb Karl Schmeer shire03@... [xpantastic]:

I would love to "enhance" the original code to allow some midi cc of parameters like filter, envelope times etc.. As well as allow midi volume control (cc #7).

Best Regards

Karl

Karl,

>>I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment.

there are 4 8K ROMS, and 3 8K RAMS on the processor board, two ROMS and two RAMS on the voice board.

The 6809 only has a 64K address space. 56K of address space is already used on the processor board.

Unless you put in a whole new circuit board to do bank switching (and rewrite the FW to go with it), you won't be able to use larger EEPROMS.

On Thu, Jun 14, 2018 at 9:03 AM, Karl Schmeer shire03@...t [xpantastic] <xpantastic@yahoogroups.com> wrote:

PeWe Wrote:

>>;"So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
>> I dunno if that´s doable via software at all, but it would be great if it were."

Hi PeWe,

This is what I am talking about. Permanently assigning some parameters to midi CC's like many current synths are capable of doing. Yes it would take

a considerable amount of understanding of the firmware, but it should be possible if enough room could be found in the ROMS. If not just have to use the slower

sysex method.

Another possibility:

I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. Using this technique it may be possible to allow more room

for added features. But I have not fully investigated this yet.

Sent you a PM

Best Karl

On Wednesday, June 13, 2018 10:12 PM, "PeWe ha-pewe@... [xpantastic]" <xpantastic@yahoogroups.com> wrote:

Hi Karl !

A bit O.T. but ...

Assigning MIDI CCs to Xpander-parameters like VCF cutoff and MIDI volume works on my Xpander uising the MIDI Controls page.

The limitation are the modulation busses,- pedals #1 & #2 and levers #1 & #2,- which isn´t enough, especially vs. the count of modulation destinations in the mod-matrix.
So, when there were a chance maxing out modulation busses in the sense of mod-sources, that would be most excellent.

There´s a bug in Multipatch-Mode when changing multi-patches via MIDI PrgCh. while MIDI CC#07 is assigned to "pedal #2" as a source and a value is being received.
The volume drops to zero then and it needs another MIDI CC#07=127 command to get some noise back from the synth.

I´m pretty sure it´s a bug because "lever #2 and "pedal #2" are "universal" (global) controllers while lever and pedal #1 work individual for each voice.
So, in Multipatch Mode, MIDI CC#07 should be the master volume controller which should work when sending a program change and volume offset command,- but it doesn´t because there´s no guarantee, the volume command arrives after the program change in exact sequential order when being transmitted from p.ex. a MIDI processor/matrix switcher or masterkeyboard.
A sequencer might handle that different compared to the devices mentioned above though.

In addition to the "master volume" functionality in "Multipatch-Mode", individual / relative volume control (not overriding MIDI CC#07 value !) for each voice should work using MIDI CC#11 together w/ MIDI CC#07 and w/o dropping overall volume to zero.
But even when we can get rid of the bug mentioned above, in Multipatch-Mode using MIDI CC#07 and MIDI CC#11 simultaneously eats up both pedals as modulation sources and makes it impossible using MIDI CC#04 for filter cutoff, may it be per voice or global,- WHEN the mod wheel is in use for vibrato p.ex..

So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
I dunno if that´s doable via software at all, but it would be great if it were.

Anyway,- now some private stuff and because it´s the occasion to send some lines ...

I received and still do receive all your emails, but when I reply, ALL the emails I send to shire03@sbcglobal.net come back to me as a mailer demon after exactly 4 (FOUR !!!) days.
I regret and have no idea what causes that behaviour, but we should try to find another way for private communication I think.
Maybe PMs @ Keybd Corner ... (???) ... what do you think ?
Please reply to my private email addy 1st.
When you agree, you might post something over there,- I´ll recognize and will jump in via PM.
Let me know please.

thx for reading

:-)

PeWe


Am 14.06.2018 um 00:02 schrieb Karl Schmeer shire03@... [xpantastic]:

I would love to "enhance" the original code to allow some midi cc of parameters like filter, envelope times etc.. As well as allow midi volume control (cc #7).

Best Regards

Karl

Karl,

>>I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment.

there are 4 8K ROMS, and 3 8K RAMS on the processor board, two ROMS and two RAMS on the voice board.

The 6809 only has a 64K address space. 56K of address space is already used on the processor board.

Unless you put in a whole new circuit board to do bank switching (and rewrite the FW to go with it), you won't be able to use larger EEPROMS.

On Thu, Jun 14, 2018 at 9:03 AM, Karl Schmeer shire03@... [xpantastic] <xpantastic@yahoogroups.com> wrote:

PeWe Wrote:

>>"So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
>> I dunno if that´s doable via software at all, but it would be great if it were."

Hi PeWe,

This is what I am talking about. Permanently assigning some parameters to midi CC's like many current synths are capable of doing. Yes it would take

a considerable amount of understanding of the firmware, but it should be possible if enough room could be found in the ROMS. If not just have to use the slower

sysex method.

Another possibility:

I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. Using this technique it may be possible to allow more room

for added features. But I have not fully investigated this yet.

Sent you a PM

Best Karl

On Wednesday, June 13, 2018 10:12 PM, "PeWe ha-pewe@... [xpantastic]" <xpantastic@yahoogroups.com> wrote:

Hi Karl !

A bit O.T. but ...

Assigning MIDI CCs to Xpander-parameters like VCF cutoff and MIDI volume works on my Xpander uising the MIDI Controls page.

The limitation are the modulation busses,- pedals #1 & #2 and levers #1 & #2,- which isn´t enough, especially vs. the count of modulation destinations in the mod-matrix.
So, when there were a chance maxing out modulation busses in the sense of mod-sources, that would be most excellent.

There´s a bug in Multipatch-Mode when changing multi-patches via MIDI PrgCh. while MIDI CC#07 is assigned to "pedal #2" as a source and a value is being received.
The volume drops to zero then and it needs another MIDI CC#07=127 command to get some noise back from the synth.

I´m pretty sure it´s a bug because "lever #2 and "pedal #2" are "universal" (global) controllers while lever and pedal #1 work individual for each voice.
So, in Multipatch Mode, MIDI CC#07 should be the master volume controller which should work when sending a program change and volume offset command,- but it doesn´t because there´s no guarantee, the volume command arrives after the program change in exact sequential order when being transmitted from p.ex. a MIDI processor/matrix switcher or masterkeyboard.
A sequencer might handle that different compared to the devices mentioned above though.

In addition to the "master volume" functionality in "Multipatch-Mode", individual / relative volume control (not overriding MIDI CC#07 value !) for each voice should work using MIDI CC#11 together w/ MIDI CC#07 and w/o dropping overall volume to zero.
But even when we can get rid of the bug mentioned above, in Multipatch-Mode using MIDI CC#07 and MIDI CC#11 simultaneously eats up both pedals as modulation sources and makes it impossible using MIDI CC#04 for filter cutoff, may it be per voice or global,- WHEN the mod wheel is in use for vibrato p.ex..

So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side.
I dunno if that´s doable via software at all, but it would be great if it were.

Anyway,- now some private stuff and because it´s the occasion to send some lines ...

I received and still do receive all your emails, but when I reply, ALL the emails I send to shire03@... come back to me as a mailer demon after exactly 4 (FOUR !!!) days.
I regret and have no idea what causes that behaviour, but we should try to find another way for private communication I think.
Maybe PMs @ Keybd Corner ... (???) ... what do you think ?
Please reply to my private email addy 1st.
When you agree, you might post something over there,- I´ll recognize and will jump in via PM.
Let me know please.

thx for reading

:-)

PeWe


Am 14.06.2018 um 00:02 schrieb Karl Schmeer shire03@... [xpantastic]:

I would love to "enhance" the original code to allow some midi cc of parameters like filter, envelope times etc.. As well as allow midi volume control (cc #7).

Best Regards

Karl

>>>

Am 15.06.2018 um 00:20 schrieb min struct min.struct@... [xpantastic]:

Hello,

Would this work bring any chance to be able to replace the 6809 CPU with an upgraded reference ?

What would happen if the CPU frequency would be 4 times the original one ?

When speeding up CPU frequency by the facor of 4,- in a synthwhere lots of modulators are realized in software, almost everything speeds up in relation,- LFO rate p.ex. and even the actually slowest possible rate.
Same w/ ENV segment times (Delay, A, D & R), Ramp times, Portamento times and so on.
No sound formerly being programmed and stored into memory would sound the same like it does today.

I know well because they got that issue w/ the "Musitronics" SpeedKit for the D50/550 w/ the target making the synth tighter when playing chords.
They got it, but after they had speed up the processor by a factor of 4 (there´s a daughterboard which fit´s the original socket, which also offers 3 more memory banks and a 2nd/separate battery in addition as also they replaced the original quartz making the clock more accurate) they had to slow down those rates mentioned above to make the synth sounding the same as it did w/ the original processor, quartz and firmware.

Would it be possible to speed up the software envelopes ? or some software modulation sources ?

In case of the ENVs, you want to make ´em snappier, not faster ... that´s the Attack/Decay times and probably also slope ...
For LFOs, you might want ´em to go faster (audio rate), but want ´em as slow as tthey originally go,- or slower in addition.
Same for Ramps.
And those things are all realized in software in Xpander/ M12

Or would it be a mess for the other controls ?

not urgently when done right.

:-)

P.