Re: [Nmedit-devel] progress on pascal port

[Marcus A. <054...@te...>]

Jan Punter wrote:
> 
> 
> Marcus Andersson & I wrote:
> 
> 
>>>Ok, MidiSpy (used on the Clavia editor) says :
>>>
>>>sysex-intro ... fc 50 1b 40 ...  etc.
> 
> 
> Which should have read as ... 7c 50 1b 40 ..., but then still this turns out to be
> just an example.
> 
> Patches can have fewer than 16 section, I had one with 10 sections today (resulting
> in 7c 4a 1b 40 ..).
> 
> 
> 
>>This suggests that from the code fragment
>>
>>>  If Not PatchStream.HasAvailble( 8)
>>>  Then Begin
>>>    Last := 1;
>>>    First := 0;
>>>  End;
>>>
>>>First := 0; could be ommitted.
>>
>>Great that you found this.
> 
> 
> This seems to be OK indeed.
> 
> 
> 
>>>I then however run into a problem with EndPositions. The list of endpositions
>>>gets exhausted now before PatchStream, resulting into access through an invalid
>>>index on EndPositions. We'll see about that.
>>
>>That is because you haven't updated midi.pdl accordingly. But if you do, you
>>will find that cc=0x1f followed by 0x50 was thought to be NewPatch. I
>>modified the following rule:
>>
>>SettingsCommand % 1 :=
>>        0:1 pp:7
>>        #pp=0x41 => SetSynthSettings$command
>>        #pp=0x50 => PatchData$next
>>        0:1 checksum:7
>>        ;
> 
> 
> Which is not the answer however.
> 
> As mentioned before 4a .. 50 should be listed (or a new sub field should be defined)
> as well.
> 
> That however doesn't work either  (information contents mismatch while adding a
> checksum) ... I'm not sure why, actually I've got no clue.

Yes, I realized this later. PatchData$next is greedy and will extract all 
integers from the intstream. This means there will be noting left for checksum:7.

> 
> What I did instead was modify the base rule into :
> 
> 
> Sysex % 1 :=
>  0xf0:8 0x33:8 0:1 cc:5 slot:2 0x06:8
>  #cc=0x00 => IAm$data
>  #cc=0x13 => Parameter$data
>  #cc=0x14 => NMInfo$data
>  #cc=0x16 => ACK$data
>  #cc=0x17 => PatchHandling$data
>  #cc=0x1c => PatchPacket$data
>  #cc=0x1d => PatchPacket$data
>  #cc=0x1e => PatchPacket$data
>  #cc=0x1f => PatchPacket$data       <---- changed here
>  0xf7:8
>  ;
> 
> This works, but this is not the final answer either I think, as now some pdl
> definitions become unreachable, and I couldn't have got it that wrong with the
> protocol crack, could I ?

When I wrote midi.pdl, I looked at your protocol information. I haven't 
implemented any other message with cc=0x1f, so I don't know if it is correct. 
  But assuming it is correct, the byte after cc/slot will indicate different 
things for values above and below 0x40. I suggest we separate this bit from 
the rest and branch on its value.

Sysex % 1 :=
	0xf0:8 0x33:8 0:1 cc:5 slot:2 0x06:8
	#cc=0x00 => IAm$data
	#cc=0x13 => Parameter$data
	#cc=0x14 => NMInfo$data
	#cc=0x16 => ACK$data
	#cc=0x17 => PatchHandling$data
	#cc=0x1c => PatchPacket$data
	#cc=0x1d => PatchPacket$data
	#cc=0x1e => PatchPacket$data
	#cc=0x1f => SettingsHandling$data
	0xf7:8
	;

...

SettingsHandling % 1 :=
	0:1 command:1
	#command=0x00 => PatchSettings$data
	#command=0x01 => SettingsCommand$data
	;

SettingsCommand % 1 :=
	pp:6
	#pp=0x01 => SetSynthSettings$command
	#pp!0x01 => PatchData$next
	;

SetSynthSettings % 1 :=
	0:1 checksum:7
	;

PatchSettings % 1 :=
	pp:6 0:1 sc:7
	#sc=0x10 => SetPatchSettings$data
	#sc=0x18 => ModuleInsertion$data
	#sc=0x21 => SEQZoom$data
	0:1 checksum:7
	;

This also means we need to add one more integer when we generate the patch 
packets:

     // Generate sysex bistream
     IntStream intStream;
     intStream.append(cc + first + 2*last);
     first = 0;
     intStream.append(slot);
     intStream.append(0x01);
     intStream.append(sectionsEnded);

What do you think?

Marcus