Casio CZ/ VZ/ FZ - Pro Series

i found  what i think is a fault with the refernce file in our file section
,, its "thong's" guide titled

----------------------------------------------------------------------------
---
----------------- CASIO CZ MIDI GUIDE  condensed
version ----------------------
----------------------------------------------------------------------------
---
---- or: Everything you Never Wanted to Know about MIDI but are going
to ------
------------------- Find Out
Anyway -------------------------------------------
----------------------------------------------------------------------------
---

        THIS IS AIMED SPECIFICALLY AT CZ101,CZ1000 and CZ5000 OWNERS.

ok to elaborate its not true when applied to the cz101

there is no byte valued over 15(DEC) or 0f(hex)
in our cz101 dump ......i asked eariler about the break down and merging of
the sys ex structure and somebody insistated that the thongs guide was
suitable ..

so i found this area is incorrect for a cz101
 -----
5) PVDLD,PVDLV

This is the vibrato delay time, transmitted in three bytes.

Delay   Bytes           Delay   Bytes           Delay   Bytes
25      19 00 19        50      32 00 4B        75      4B 00 DF
26      1A 00 1A        51      33 00 4F        76      4C 00 E7
27      1B 00 1B        52      34 00 53        77      4D 00 EF
28      1C 00 1C        53      35 00 57        78      4E 00 F7
29      1D 00 1D        54      36 00 5B        79      4F 00 FF
30      1E 00 1E        55      37 00 5F        80      50 01 0F
31      1F 00 1F        56      38 00 63        81      51 01 1F
32      20 00 21        57      39 00 67        82      52 01 2F
33      21 00 23        58      3A 00 6B        83      53 01 3F
34      22 00 25        59      3B 00 6F        84      54 01 4F
35      23 00 27        60      3C 00 73        85      55 01 5F
36      24 00 29        61      3D 00 77        86      56 01 6F
37      25 00 2B        62      3E 00 7B        87      67 01 7F
38      26 00 2D        63      3F 00 7F        88      58 01 8F
39      27 00 2F        64      40 00 87        89      59 01 9F
40      28 00 31        65      41 00 8F        90      5A 01 AF
41      29 00 33        66      42 00 97        91      5B 01 BF
42      2A 00 35        67      43 00 9F        92      5C 01 CF
43      2B 00 37        68      44 00 A7        93      5D 01 DF
44      2C 00 39        69      45 00 AF        94      5E 01 EF
45      2D 00 3B        70      46 00 B7        95      5F 01 FF
46      2E 00 3D        71      47 00 BF        96      60 02 1F
47      2F 00 3F        72      48 00 C7        97      61 02 3F
48      30 00 43        73      49 00 CF        98      62 02 5F
49      31 00 47        74      4A 00 D7        99      63 02 7F

For delays in the range 0..31, just transmit 00..1F, 00, 00..1F eg for delay
of 12, send 0C 00 0C. This is convenient since it saves me typing in another
column of boring numbers ;-)

6) PVSD,PVSV

Again, here comes another table for conversions. The first column (0..24) is
omitted since the only difficult thing needed is to add 01 00 20 to each
entry
( The first few go 00 00 20, 01 00 40, 02 00 60, ... 06 00 E0, 07 01 00, ..)

Rate    Bytes           Rate    Bytes           Rate    Bytes
25      19 03 40        50      32 09 E0        75      4B 1C E0
26      1A 03 60        51      33 0A 60        76      4C 1D E0
27      1B 03 80        52      34 0A E0        77      4D 1E E0
28      1C 03 A0        53      35 0B 60        78      4E 1F E0
29      1D 03 C0        54      36 0B E0        79      4F 20 E0
30      1E 03 E0        55      37 0C 60        80      50 23 E0
31      1F 04 00        56      38 0C E0        81      51 25 E0
32      20 04 60        57      39 0D 60        82      52 27 E0
33      21 04 A0        58      3A 0D E0        83      53 29 E0
34      22 04 E0        59      3B 0E 60        84      54 2B E0
35      23 05 20        60      3C 0E E0        85      55 2D E0
36      24 05 60        61      3D 0F 60        86      56 2F E0
37      25 05 A0        62      3E 0F E0        87      57 31 E0
38      26 05 E0        63      3F 10 60        88      58 33 E0
39      27 06 20        64      40 11 E0        89      59 35 E0
40      28 06 60        65      41 12 E0        90      5A 37 E0
41      29 06 A0        66      42 13 E0        91      5B 39 E0
42      2A 06 E0        67      43 14 E0        92      5C 3B E0
43      2B 07 20        68      44 15 E0        93      5D 3D E0
44      2C 07 60        69      45 16 E0        94      5E 3F E0
45      2D 07 A0        70      46 17 E0        95      5F 41 E0
46      2E 07 E0        71      47 18 E0        96      60 47 E0
47      2F 08 20        72      48 19 E0        97      61 4B E0
48      30 08 E0        73      49 1A E0        98      62 4F E0
49      31 09 60        74      4A 1B E0        99      63 53 E0

7) PVDD,PVDV

These are again encoded as three bytes in a most obscure way. Below 32, the
encoding is 00..1F, 00, 01..20 eg for depth 13, send 0D 00 0E.

Depth   Bytes           Depth   Bytes           Depth   Bytes
25      19 00 1A        50      32 00 4F        75      4B 00 E7
26      1A 00 1B        51      33 00 53        76      4C 00 EF
27      1B 00 1C        52      34 00 57        77      4D 00 F7
28      1C 00 1D        53      35 00 5B        78      4E 00 FF
29      1D 00 1E        54      36 00 5F        79      4F 01 07
30      1E 00 1F        55      37 00 63        80      50 01 1F
31      1F 00 20        56      38 00 67        81      51 01 2F
32      20 00 23        57      39 00 6B        82      52 01 3F
33      21 00 25        58      3A 00 6F        83      53 01 4F
34      22 00 27        59      3B 00 73        84      54 01 5F
35      23 00 29        60      3C 00 77        85      55 01 6F
36      24 00 2B        61      3D 00 7B        86      56 01 7F
37      25 00 2D        62      3E 00 7F        87      57 01 8F
38      26 00 2F        63      3F 00 83        88      58 01 9F
39      27 00 31        64      40 00 8F        89      59 01 AF
40      28 00 33        65      41 00 97        90      5A 01 BF
41      29 00 35        66      42 00 9F        91      5B 01 CF
42      2A 00 37        67      43 00 A7        92      5C 01 DF
43      2B 00 39        68      44 00 AF        93      5D 01 EF
44      2C 00 3B        69      45 00 B7        94      5E 01 FF
45      2D 00 3D        70      46 00 BF        95      5F 02 0F
46      2E 00 3F        71      47 00 C7        96      60 02 3F
47      2F 00 41        72      48 00 CF        97      61 02 5F
48      30 00 47        73      49 00 D7        98      62 02 7F
49      31 00 4B        74      4A 00 DF        99      63 03 00


--------
maybe the bit formation is true in this table (i never checked!)
 but  63(hex) or 99(dec) does never show up in the contents of a sysex dump
from a cz101...
therefore why should it go out to the cz101?

anybody  able to correct me  and leed me in right direction?
i am very certain when 99 is parameter
it shows up in the sysex as  3,6,15,7,2

 and then there is the remaining option to
add or 'or'
its position in the sysex with other overlapping parameters.

so help where you can everybody ..

charles

Back up a bit:  What are you trying to do? Are you trying to derive a mathematical formula that correlates the time and internal values?

So far as I can tell from the Casio manual, PVDLD is just the Vibrato Delay Display (the scaled rate in hex from 0 to 99 [0x00 to 0x63]) and the PVDLV is the corresponding timing value.

Note: It may be possible to send preset via sysex with values other than what's in the PVDLV columns. I know you can put non-standard data into the CZ, but I haven't specifically tested these parameters.

> there is no byte valued over 15(DEC) or 0f(hex)

HUH?  Don't you mean 127 or 0x7F? Is it possible you are splitting the already nybblized data a second time? Your sysex routine should get 0xF0 at the start, 0xF7 at the end, and numbers from 0x00 and 0x7F, inclusive, in between. If you are not getting the 0xF0 and 0xF7, then your routine is not correct. If you are getting 0x0F and 0x00 as your first two bytes with 0x0F and 0x07 as your last two bytes, you are spliting them in half.

What language are you programming in?



> This is the vibrato delay time, transmitted in three bytes.
> 
> Delay   Bytes           Delay   Bytes           Delay   Bytes
> 25      19 00 19        50      32 00 4B        75      4B 00 DF

25 = decimal
19 = display value of 25 in hex
00 19 = the internal vibrato delay time.

> For delays in the range 0..31, just transmit 00..1F, 00, 00..1F eg for delay
> of 12, send 0C 00 0C. This is convenient since it saves me typing in another
> column of boring numbers ;-)

Have you figured out a way to trasmit only part of a preset to a CZ?  I thought it was impossible.

> 6) PVSD,PVSV
> 
> Again, here comes another table for conversions. The first column (0..24) is
> omitted since the only difficult thing needed is to add 01 00 20 to each
> entry
> ( The first few go 00 00 20, 01 00 40, 02 00 60, ... 06 00 E0, 07 01 00, ..)
> 
> Rate    Bytes           Rate    Bytes           Rate    Bytes
> 25      19 03 40        50      32 09 E0        75      4B 1C E0

Again:
25 is the decimal number that shows in the display.
19 is the hex number for 25
03 40 is the internal value that represents the Vibrato Rate when the display reads 25.


> 7) PVDD,PVDV
 
> These are again encoded as three bytes in a most obscure way. 

What are you trying to figure out? There is no mystery. There are probably only two possibilities (maybe with some variations):
(1) There is a mathematical formula to scale the Vibrato Rate (in this case) over the span of 100 numbers (0 -> 99).
(2) There is a table that the CZ uses.
I would infer (1) with the assumption being that the scale is non-linear. (Or rather, the scale is linear, but the rates are not.) If you want, why not test to see if a displayed rate of 80 is eight times the rate when 10 is displayed?

Below 32, the
> encoding is 00..1F, 00, 01..20 eg for depth 13, send 0D 00 0E.
> 
> Depth   Bytes           Depth   Bytes           Depth   Bytes
> 25      19 00 1A        50      32 00 4F        75      4B 00 E7

> --------
> maybe the bit formation is true in this table (i never checked!)
>  but  63(hex) or 99(dec) does never show up in the contents of a sysex dump
> from a cz101...
> therefore why should it go out to the cz101?

Do me a favor: create a CZ patch has the following values set to 99 in the display:
--Vibrato Delay Rate
--Vibrato Rate
--Vibrato Depth
Download it as a sysex file and upload it to the file section. I want to see this for myself.  I'd do it, but I don't have my CZ set up.

> anybody  able to correct me  and leed me in right direction?
> i am very certain when 99 is parameter
> it shows up in the sysex as  3,6,15,7,2

LOL!!!

You are splitting them up and reversing the order of the split up nybbles!!!!!!

03, 06 is really 0x63
15 is the 0x0F that goes with the 7 to make 0x7F
2 is really the 0x02 in the middle!!!!

Gee, this is more fun than doing a jigsaw puzzle!!!

In short, for a Vibrato Delay Time that corresponds to the display value of 99, 0x63 is the hex representation of the displayed value (PVDLD), 0x02 is the MSB of the PVDLV data and 0x7F is the LSB of the PVDLV.

That's exactly what's in the table!!!!!!

I think you have been staring at either your code or the table too long.

BTW, maybe you can use the DCA, DCW, and DCO conversion "formulas" in the Casio "Guidebook for MIDI" to generate the vibrato formulas.  I suggest using a speadsheet, with one column for the display value (in decimal) and another column for the internal value (converted to decimal). Then create a third column for the difference between each of the values in column. You might see that there is a "curve" that looks like several line segments due to rounding of a non-linear progression. (From 1 to 31 the delta is 1; from 31 to 47, the delta is 2, from 47 to 63, the delta is 3; from 63 to 79, the delta is 8; from 79 to 95, the delta is 16; from 95 to 99, the delta is 32.

Hope this helps.

--Steve

hi steve , somebody off the list has already made me aware that these 256
bytes i get from the cz101 need merged to form 128 bytes  which form larger
numbers .. i am always gung -ho  to embark on my programming

what i what to do is find how the data is split , from 128 bytes into 256 ..
thongs memo said  that 5f  is sent 0x0f 0x05 but  this now means i have to
shift my area of focus from deciphering sys ex into writijng an algo that
splits hex numbers from alpha representation ..

any sence yet?

charles

----- Original Message -----
From: "steve_the_composer" <smw-mail@...>
To: <CZsynth@yahoogroups.com>
Sent: Monday, August 10, 2009 12:42 PM
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown


> Back up a bit:  What are you trying to do? Are you trying to derive a
mathematical formula that correlates the time and internal values?
>
> So far as I can tell from the Casio manual, PVDLD is just the Vibrato
Delay Display (the scaled rate in hex from 0 to 99 [0x00 to 0x63]) and the
PVDLV is the corresponding timing value.
>
> Note: It may be possible to send preset via sysex with values other than
what's in the PVDLV columns. I know you can put non-standard data into the
CZ, but I haven't specifically tested these parameters.
>
> > there is no byte valued over 15(DEC) or 0f(hex)
>
> HUH?  Don't you mean 127 or 0x7F? Is it possible you are splitting the
already nybblized data a second time? Your sysex routine should get 0xF0 at
the start, 0xF7 at the end, and numbers from 0x00 and 0x7F, inclusive, in
between. If you are not getting the 0xF0 and 0xF7, then your routine is not
correct. If you are getting 0x0F and 0x00 as your first two bytes with 0x0F
and 0x07 as your last two bytes, you are spliting them in half.
>
> What language are you programming in?
>
>
>
> > This is the vibrato delay time, transmitted in three bytes.
> >
> > Delay   Bytes           Delay   Bytes           Delay   Bytes
> > 25      19 00 19        50      32 00 4B        75      4B 00 DF
>
> 25 = decimal
> 19 = display value of 25 in hex
> 00 19 = the internal vibrato delay time.
>
> > For delays in the range 0..31, just transmit 00..1F, 00, 00..1F eg for
delay
> > of 12, send 0C 00 0C. This is convenient since it saves me typing in
another
> > column of boring numbers ;-)
>
> Have you figured out a way to trasmit only part of a preset to a CZ?  I
thought it was impossible.
>
> > 6) PVSD,PVSV
> >
> > Again, here comes another table for conversions. The first column
(0..24) is
> > omitted since the only difficult thing needed is to add 01 00 20 to each
> > entry
> > ( The first few go 00 00 20, 01 00 40, 02 00 60, ... 06 00 E0, 07 01 00,
..)
> >
> > Rate    Bytes           Rate    Bytes           Rate    Bytes
> > 25      19 03 40        50      32 09 E0        75      4B 1C E0
>
> Again:
> 25 is the decimal number that shows in the display.
> 19 is the hex number for 25
> 03 40 is the internal value that represents the Vibrato Rate when the
display reads 25.
>
>
> > 7) PVDD,PVDV
>
> > These are again encoded as three bytes in a most obscure way.
>
> What are you trying to figure out? There is no mystery. There are probably
only two possibilities (maybe with some variations):
> (1) There is a mathematical formula to scale the Vibrato Rate (in this
case) over the span of 100 numbers (0 -> 99).
> (2) There is a table that the CZ uses.
> I would infer (1) with the assumption being that the scale is non-linear.
(Or rather, the scale is linear, but the rates are not.) If you want, why
not test to see if a displayed rate of 80 is eight times the rate when 10 is
displayed?
>
> Below 32, the
> > encoding is 00..1F, 00, 01..20 eg for depth 13, send 0D 00 0E.
> >
> > Depth   Bytes           Depth   Bytes           Depth   Bytes
> > 25      19 00 1A        50      32 00 4F        75      4B 00 E7
>
> > --------
> > maybe the bit formation is true in this table (i never checked!)
> >  but  63(hex) or 99(dec) does never show up in the contents of a sysex
dump
> > from a cz101...
> > therefore why should it go out to the cz101?
>
> Do me a favor: create a CZ patch has the following values set to 99 in the
display:
> --Vibrato Delay Rate
> --Vibrato Rate
> --Vibrato Depth
> Download it as a sysex file and upload it to the file section. I want to
see this for myself.  I'd do it, but I don't have my CZ set up.
>
> > anybody  able to correct me  and leed me in right direction?
> > i am very certain when 99 is parameter
> > it shows up in the sysex as  3,6,15,7,2
>
> LOL!!!
>
> You are splitting them up and reversing the order of the split up
nybbles!!!!!!
>
> 03, 06 is really 0x63
> 15 is the 0x0F that goes with the 7 to make 0x7F
> 2 is really the 0x02 in the middle!!!!
>
> Gee, this is more fun than doing a jigsaw puzzle!!!
>
> In short, for a Vibrato Delay Time that corresponds to the display value
of 99, 0x63 is the hex representation of the displayed value (PVDLD), 0x02
is the MSB of the PVDLV data and 0x7F is the LSB of the PVDLV.
>
> That's exactly what's in the table!!!!!!
>
> I think you have been staring at either your code or the table too long.
>
> BTW, maybe you can use the DCA, DCW, and DCO conversion "formulas" in the
Casio "Guidebook for MIDI" to generate the vibrato formulas.  I suggest
using a speadsheet, with one column for the display value (in decimal) and
another column for the internal value (converted to decimal). Then create a
third column for the difference between each of the values in column. You
might see that there is a "curve" that looks like several line segments due
to rounding of a non-linear progression. (From 1 to 31 the delta is 1; from
31 to 47, the delta is 2, from 47 to 63, the delta is 3; from 63 to 79, the
delta is 8; from 79 to 95, the delta is 16; from 95 to 99, the delta is 32.

>
> Hope this helps.
>
> --Steve
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles - deriving the actual value of the parameter should be a matter of using Thong's table of values.
 
Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.
I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.
I already have a Commodore program which creates random data for the CZ - but this is not very effective.
I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.
Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!
Deriving the paramters is thence a matter of masking the bits as per Thongs table.

--- On Mon, 10/8/09, steve_the_composer <smw-mail@...> wrote:

From: steve_the_composer <smw-mail@...>
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
To: CZsynth@yahoogroups.com
Date: Monday, 10 August, 2009, 8:42 PM


  



Back up a bit: What are you trying to do? Are you trying to derive a mathematical formula that correlates the time and internal values?

So far as I can tell from the Casio manual, PVDLD is just the Vibrato Delay Display (the scaled rate in hex from 0 to 99 [0x00 to 0x63]) and the PVDLV is the corresponding timing value.

Note: It may be possible to send preset via sysex with values other than what's in the PVDLV columns. I know you can put non-standard data into the CZ, but I haven't specifically tested these parameters.

> there is no byte valued over 15(DEC) or 0f(hex)

HUH? Don't you mean 127 or 0x7F? Is it possible you are splitting the already nybblized data a second time? Your sysex routine should get 0xF0 at the start, 0xF7 at the end, and numbers from 0x00 and 0x7F, inclusive, in between. If you are not getting the 0xF0 and 0xF7, then your routine is not correct. If you are getting 0x0F and 0x00 as your first two bytes with 0x0F and 0x07 as your last two bytes, you are spliting them in half.

What language are you programming in?

> This is the vibrato delay time, transmitted in three bytes.
> 
> Delay Bytes Delay Bytes Delay Bytes
> 25 19 00 19 50 32 00 4B 75 4B 00 DF

25 = decimal
19 = display value of 25 in hex
00 19 = the internal vibrato delay time.

> For delays in the range 0..31, just transmit 00..1F, 00, 00..1F eg for delay
> of 12, send 0C 00 0C. This is convenient since it saves me typing in another
> column of boring numbers ;-)

Have you figured out a way to trasmit only part of a preset to a CZ? I thought it was impossible.

> 6) PVSD,PVSV
> 
> Again, here comes another table for conversions. The first column (0..24) is
> omitted since the only difficult thing needed is to add 01 00 20 to each
> entry
> ( The first few go 00 00 20, 01 00 40, 02 00 60, ... 06 00 E0, 07 01 00, ..)
> 
> Rate Bytes Rate Bytes Rate Bytes
> 25 19 03 40 50 32 09 E0 75 4B 1C E0

Again:
25 is the decimal number that shows in the display.
19 is the hex number for 25
03 40 is the internal value that represents the Vibrato Rate when the display reads 25.

> 7) PVDD,PVDV

> These are again encoded as three bytes in a most obscure way. 

What are you trying to figure out? There is no mystery. There are probably only two possibilities (maybe with some variations):
(1) There is a mathematical formula to scale the Vibrato Rate (in this case) over the span of 100 numbers (0 -> 99).
(2) There is a table that the CZ uses.
I would infer (1) with the assumption being that the scale is non-linear. (Or rather, the scale is linear, but the rates are not.) If you want, why not test to see if a displayed rate of 80 is eight times the rate when 10 is displayed?

Below 32, the
> encoding is 00..1F, 00, 01..20 eg for depth 13, send 0D 00 0E.
> 
> Depth Bytes Depth Bytes Depth Bytes
> 25 19 00 1A 50 32 00 4F 75 4B 00 E7

> --------
> maybe the bit formation is true in this table (i never checked!)
> but 63(hex) or 99(dec) does never show up in the contents of a sysex dump
> from a cz101...
> therefore why should it go out to the cz101?

Do me a favor: create a CZ patch has the following values set to 99 in the display:
--Vibrato Delay Rate
--Vibrato Rate
--Vibrato Depth
Download it as a sysex file and upload it to the file section. I want to see this for myself. I'd do it, but I don't have my CZ set up.

> anybody able to correct me and leed me in right direction?
> i am very certain when 99 is parameter
> it shows up in the sysex as 3,6,15,7,2

LOL!!!

You are splitting them up and reversing the order of the split up nybbles!!!!! !

03, 06 is really 0x63
15 is the 0x0F that goes with the 7 to make 0x7F
2 is really the 0x02 in the middle!!!!

Gee, this is more fun than doing a jigsaw puzzle!!!

In short, for a Vibrato Delay Time that corresponds to the display value of 99, 0x63 is the hex representation of the displayed value (PVDLD), 0x02 is the MSB of the PVDLV data and 0x7F is the LSB of the PVDLV.

That's exactly what's in the table!!!!!!

I think you have been staring at either your code or the table too long.

BTW, maybe you can use the DCA, DCW, and DCO conversion "formulas" in the Casio "Guidebook for MIDI" to generate the vibrato formulas. I suggest using a speadsheet, with one column for the display value (in decimal) and another column for the internal value (converted to decimal). Then create a third column for the difference between each of the values in column. You might see that there is a "curve" that looks like several line segments due to rounding of a non-linear progression. (From 1 to 31 the delta is 1; from 31 to 47, the delta is 2, from 47 to 63, the delta is 3; from 63 to 79, the delta is 8; from 79 to 95, the delta is 16; from 95 to 99, the delta is 32.

Hope this helps.

--Steve

















      

[Non-text portions of this message have been removed]

Thanks for the clarification, Lee. This helps me to understand what you guys are trying to do.

I know what you mean about some CZ patch dump data needing to be handled on a bit-by-bit basis. However, unless I am missing something I don't see any where any parameters are split up. You have some 8-bit and 16-bit [not nybblized] structures where the different bits mean different things. 

See previous message with hex, binary, and decimal explanations of (1) nybblizing and (2) reassembling the nybbles.

Also, see the files section where I posted 2 sections of C-64 assembly code showing (1) and (2) with comments added today to correlate with http://launch.groups.yahoo.com/group/CZsynth/message/4111.

Also, see comments below.

--- In CZsynth@yahoogroups.com, Lee Borrell <templarser@...> wrote:
>
> Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles -

STEVE: For consistency, you might want to reassemble nyblized data first when receiving it.

> deriving the actual value of the parameter should be a matter of using Thong's table of values.

STEVE: Since Thong basically took Casio's Midi Guide book and added comments to try to explain what the graphics show in the original, I would really recommend the original. 
  
> Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. 

STEVE: I have used basic, but I have no idea what GFA basic is.

> I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.

STEVE: You should see Korg's EX-800/Poly-800 packed patch data; it is all bit-wise sequential!! Does GFA Basic let you operate in hex or binary? Or is it all decimal? Did you ever work with Roland's midi data structures? It is complex, but at least they gave the address of individual parameters. I think that's what lot's of CZ/VZ users wish CAsio had done.

> I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.

STEVE: This makes sense; I just couldn't figure out why Charlie was confused by the tables. I would think a look up simple array would do it. Get the two timing bytes as an offset from the start of the array based on the display value.  

> I already have a Commodore program which creates random data for the CZ - but this is not very effective.

> I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.

> Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!

STEVE: YUP, if I understand what you mean here.
Reassembled Byte = Nybble(1) + Nybble(2) * 2^4

> Deriving the paramters is thence a matter of masking the bits as per Thongs table.

STEVE: YUP, just so long as (1) each 8-bit structure is split/nybblized or reassembled properly and (2) you realize that PVDLD is simply the display value and PVDLV is a set of 2 8-bit values. 

Sounds like an interesting project. Let me know if I can help.

--Steve

PS: In looking at my C-64 code, I do believe the nybbles are sent and received in lsb/msb order for each 8-bit structure. Thus for a 16-but structure you would the order would be MSBlsb MSBmsb LSBlsb LSBmsb.  In other words, for a Delay Time represented on the screen by = 96 (dec), the nybblized PVDLV sequence would be 2 0 15 1 (dec).

2 + (0 *16) is the MSB 
15 + (1 * 16) is the LSB

In the table this appears as 60 02 1F (hex)

yeah the cz101 sys ex dump differs  tremendousilly from the pss dump because
the pss
only shares bits in a byte value ,,
 it outputs just the same as its read ,,
where ,
 now if i'm correct ,
the cz needs divded in half  to be read
then merged back into 256 bytes ...to be transmitted

.which has me question-ing and pondering , why?

ok the good advice always arrives at the wort time..busy doing dishes , b
back later..

 charles

yep acknowledged lee ,good deduc-ing,
 busy right now,
 b back later with more decent input.

charles

----- Original Message -----
From: "Lee Borrell" <templarser@...>
To: <CZsynth@yahoogroups.com>
Sent: Tuesday, August 11, 2009 9:22 AM
Subject: Re: [CZsynth] Re: help cz101 bytes sysex breakdown


Regardless of the nybble arrangement of the CZ - once the data bytes are in
place inside a PC/computer the problem is the whereabouts of the bits,which
are sometimes placed across nybbles - deriving the actual value of the
parameter should be a matter of using Thong's table of values.

Charlie and myself are trying to use GFA basic - but I am unfamiliar with
this. I have wrote programs to exploit the PSS series SYSx in Commodore
basic - which worked admirably - Yamaha didn't make quite such a mess of the
Sysx table and the parameters seem easier to derive.
I do not believe that we need formulae for time-wise versions of anything -
only the actual decimal data from which to derive the parameters - to be
edited - before sending them back to the CZ.
I already have a Commodore program which creates random data for the CZ -
but this is not very effective.
I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles)
which of course never exceed 15 within the header and trailer bytes.
Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 -
creating a byte of 8bits= 15+15*16 - getting them in the correct order is a
must!
Deriving the paramters is thence a matter of masking the bits as per Thongs
table.

--- On Mon, 10/8/09, steve_the_composer <smw-mail@...> wrote:


From: steve_the_composer <smw-mail@...>
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
To: CZsynth@yahoogroups.com
Date: Monday, 10 August, 2009, 8:42 PM






Back up a bit: What are you trying to do? Are you trying to derive a
mathematical formula that correlates the time and internal values?

So far as I can tell from the Casio manual, PVDLD is just the Vibrato Delay
Display (the scaled rate in hex from 0 to 99 [0x00 to 0x63]) and the PVDLV
is the corresponding timing value.

Note: It may be possible to send preset via sysex with values other than
what's in the PVDLV columns. I know you can put non-standard data into the
CZ, but I haven't specifically tested these parameters.

> there is no byte valued over 15(DEC) or 0f(hex)

HUH? Don't you mean 127 or 0x7F? Is it possible you are splitting the
already nybblized data a second time? Your sysex routine should get 0xF0 at
the start, 0xF7 at the end, and numbers from 0x00 and 0x7F, inclusive, in
between. If you are not getting the 0xF0 and 0xF7, then your routine is not
correct. If you are getting 0x0F and 0x00 as your first two bytes with 0x0F
and 0x07 as your last two bytes, you are spliting them in half.

What language are you programming in?

> This is the vibrato delay time, transmitted in three bytes.
>
> Delay Bytes Delay Bytes Delay Bytes
> 25 19 00 19 50 32 00 4B 75 4B 00 DF

25 = decimal
19 = display value of 25 in hex
00 19 = the internal vibrato delay time.

> For delays in the range 0..31, just transmit 00..1F, 00, 00..1F eg for
delay
> of 12, send 0C 00 0C. This is convenient since it saves me typing in
another
> column of boring numbers ;-)

Have you figured out a way to trasmit only part of a preset to a CZ? I
thought it was impossible.

> 6) PVSD,PVSV
>
> Again, here comes another table for conversions. The first column (0..24)
is
> omitted since the only difficult thing needed is to add 01 00 20 to each
> entry
> ( The first few go 00 00 20, 01 00 40, 02 00 60, ... 06 00 E0, 07 01 00,
..)
>
> Rate Bytes Rate Bytes Rate Bytes
> 25 19 03 40 50 32 09 E0 75 4B 1C E0

Again:
25 is the decimal number that shows in the display.
19 is the hex number for 25
03 40 is the internal value that represents the Vibrato Rate when the
display reads 25.

> 7) PVDD,PVDV

> These are again encoded as three bytes in a most obscure way.

What are you trying to figure out? There is no mystery. There are probably
only two possibilities (maybe with some variations):
(1) There is a mathematical formula to scale the Vibrato Rate (in this case)
over the span of 100 numbers (0 -> 99).
(2) There is a table that the CZ uses.
I would infer (1) with the assumption being that the scale is non-linear.
(Or rather, the scale is linear, but the rates are not.) If you want, why
not test to see if a displayed rate of 80 is eight times the rate when 10 is
displayed?

Below 32, the
> encoding is 00..1F, 00, 01..20 eg for depth 13, send 0D 00 0E.
>
> Depth Bytes Depth Bytes Depth Bytes
> 25 19 00 1A 50 32 00 4F 75 4B 00 E7

> --------
> maybe the bit formation is true in this table (i never checked!)
> but 63(hex) or 99(dec) does never show up in the contents of a sysex dump
> from a cz101...
> therefore why should it go out to the cz101?

Do me a favor: create a CZ patch has the following values set to 99 in the
display:
--Vibrato Delay Rate
--Vibrato Rate
--Vibrato Depth
Download it as a sysex file and upload it to the file section. I want to see
this for myself. I'd do it, but I don't have my CZ set up.

> anybody able to correct me and leed me in right direction?
> i am very certain when 99 is parameter
> it shows up in the sysex as 3,6,15,7,2

LOL!!!

You are splitting them up and reversing the order of the split up
nybbles!!!!! !

03, 06 is really 0x63
15 is the 0x0F that goes with the 7 to make 0x7F
2 is really the 0x02 in the middle!!!!

Gee, this is more fun than doing a jigsaw puzzle!!!

In short, for a Vibrato Delay Time that corresponds to the display value of
99, 0x63 is the hex representation of the displayed value (PVDLD), 0x02 is
the MSB of the PVDLV data and 0x7F is the LSB of the PVDLV.

That's exactly what's in the table!!!!!!

I think you have been staring at either your code or the table too long.

BTW, maybe you can use the DCA, DCW, and DCO conversion "formulas" in the
Casio "Guidebook for MIDI" to generate the vibrato formulas. I suggest using
a speadsheet, with one column for the display value (in decimal) and another
column for the internal value (converted to decimal). Then create a third
column for the difference between each of the values in column. You might
see that there is a "curve" that looks like several line segments due to
rounding of a non-linear progression. (From 1 to 31 the delta is 1; from 31
to 47, the delta is 2, from 47 to 63, the delta is 3; from 63 to 79, the
delta is 8; from 79 to 95, the delta is 16; from 95 to 99, the delta is 32.

Hope this helps.

--Steve



















[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

http://templarseries.atspace.com/cz.html
 
I mapped the CZ bytes going by Thong's map - as far as I can see the first few bytes use both nybbles - byte3,4,5 and thus the parameter is stretched across two nybbles - once those nybbles are collected as a byte it should be just a matter of masking the bits and dividing by an appropriate integer much as Charles suggested.
At least - this is what I think I did with the PSS programs - byte 15/16 are in a similar position. But then I am not totally sure the map is correct.
I cannot see any 16 bit structures from my map - but it is a rough draft to get the basic layout of the bytes for any given parameter.
Essentially the map indicates that the Sysx structure comprises common parameters first and then 2sets of 3 blocks for each DCO comprising the DCA,DCW and DCO envelope controls.


--- On Tue, 11/8/09, steve_the_composer <smw-mail@...> wrote:

From: steve_the_composer <smw-mail@...>
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
To: CZsynth@yahoogroups.com
Date: Tuesday, 11 August, 2009, 7:04 PM


  



Thanks for the clarification, Lee. This helps me to understand what you guys are trying to do.

I know what you mean about some CZ patch dump data needing to be handled on a bit-by-bit basis. However, unless I am missing something I don't see any where any parameters are split up. You have some 8-bit and 16-bit [not nybblized] structures where the different bits mean different things. 

See previous message with hex, binary, and decimal explanations of (1) nybblizing and (2) reassembling the nybbles.

Also, see the files section where I posted 2 sections of C-64 assembly code showing (1) and (2) with comments added today to correlate with http://launch. groups.yahoo. com/group/ CZsynth/message/ 4111.

Also, see comments below.

--- In CZsynth@yahoogroups .com, Lee Borrell <templarser@ ...> wrote:
>
> Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles -

STEVE: For consistency, you might want to reassemble nyblized data first when receiving it.

> deriving the actual value of the parameter should be a matter of using Thong's table of values.

STEVE: Since Thong basically took Casio's Midi Guide book and added comments to try to explain what the graphics show in the original, I would really recommend the original. 
 
> Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. 

STEVE: I have used basic, but I have no idea what GFA basic is.

> I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.

STEVE: You should see Korg's EX-800/Poly- 800 packed patch data; it is all bit-wise sequential!! Does GFA Basic let you operate in hex or binary? Or is it all decimal? Did you ever work with Roland's midi data structures? It is complex, but at least they gave the address of individual parameters. I think that's what lot's of CZ/VZ users wish CAsio had done.

> I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.

STEVE: This makes sense; I just couldn't figure out why Charlie was confused by the tables. I would think a look up simple array would do it. Get the two timing bytes as an offset from the start of the array based on the display value. 

> I already have a Commodore program which creates random data for the CZ - but this is not very effective.

> I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.

> Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!

STEVE: YUP, if I understand what you mean here.
Reassembled Byte = Nybble(1) + Nybble(2) * 2^4

> Deriving the paramters is thence a matter of masking the bits as per Thongs table.

STEVE: YUP, just so long as (1) each 8-bit structure is split/nybblized or reassembled properly and (2) you realize that PVDLD is simply the display value and PVDLV is a set of 2 8-bit values. 

Sounds like an interesting project. Let me know if I can help.

--Steve

PS: In looking at my C-64 code, I do believe the nybbles are sent and received in lsb/msb order for each 8-bit structure. Thus for a 16-but structure you would the order would be MSBlsb MSBmsb LSBlsb LSBmsb. In other words, for a Delay Time represented on the screen by = 96 (dec), the nybblized PVDLV sequence would be 2 0 15 1 (dec).

2 + (0 *16) is the MSB 
15 + (1 * 16) is the LSB

In the table this appears as 60 02 1F (hex)

















      

[Non-text portions of this message have been removed]

Its really a matter of personal choice how anyone develops a program. Someone might perfer to think of a particular sysex dump as a long chain of bits. Another person might think of a paticular dump as as a chain of consecutive 4-bit nybbles.

To me, byte 2 is the Patch Detune Sign, is called PDS in the original Casio Guidebook, and uses only the lowest bit such that 0 represents + and 1 represents -.

Byte 3 is Patch Detune High, is called PDETH by Casio, and uses the 6 lowest bits to represent detune in semitone increments, while byte 4 is Patch Detune Lo, is called PDETL by Casio, and uses the 6 highest bits to represent fine detuning (less that one semitone).

I can see that on the basis of bytes, nybbles, and bits, respectively, the CZ detune parameter is represented by 3 8-bit bytes, 6 4-bit nybbles, and 13 bits. I was originally thinking of the PDS as a single bit which is followed by a 16-bit structure (with some unused bits). They all refer to the same thing.

The Patch Vibrato Delay Value (which Casio calls PVDV) can be considered as one 16-bit structure, a pair of two 8-bit structures, 4 4-bit nybbles, or a sequence of 16 bits.

PVDLD/PVDLV can be thought of as a series of 3 8-bit bytes, 6 4-bit nybbles, or 24 bits. I was thinking of PVDLD and PVDLV as two different (but related) parameters. Thus, PVDLD is 8 bits and PVDLV is 16-bits, (Of course since the highest value in the table is 02 7F, one of the nybbles will always be 0!!)

(I am not sure, but you might want to check to see if you can put in a data value that does not correspons with the published value for a specific display value.  For example, can you have the display showing 99 while the data is 0?)

I suppose if a program is developed as a string of nybbles, it might be helpful to think of PVDV as crossing the boundaries of four nybbles. Whatever it takes for you guys to keep it straight is great.

The on-line map looks nice (very colorful). As you add the details and confirm things, it should serve as a handy resource. 

Keep us posted on the progress.

BTW, I looked up GFA Basic. Evidently this was originally for Ataris, but I see there are some 32 bit versions for 32 bit computers.

--Steve

-- In CZsynth@yahoogroups.com, Lee Borrell <templarser@...> wrote:

>
> http://templarseries.atspace.com/cz.html
>  
> I mapped the CZ bytes going by Thong's map - as far as I can see the first few bytes use both nybbles - byte3,4,5 and thus the parameter is stretched across two nybbles - once those nybbles are collected as a byte it should be just a matter of masking the bits and dividing by an appropriate integer much as Charles suggested.
> At least - this is what I think I did with the PSS programs - byte 15/16 are in a similar position. But then I am not totally sure the map is correct.
> I cannot see any 16 bit structures from my map - but it is a rough draft to get the basic layout of the bytes for any given parameter.
> Essentially the map indicates that the Sysx structure comprises common parameters first and then 2sets of 3 blocks for each DCO comprising the DCA,DCW and DCO envelope controls.
> 
> 
> --- On Tue, 11/8/09, steve_the_composer <smw-mail@...> wrote:
> 
> 
> From: steve_the_composer <smw-mail@...>
> Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
> To: CZsynth@yahoogroups.com
> Date: Tuesday, 11 August, 2009, 7:04 PM
> 
> 
>   
> 
> 
> 
> Thanks for the clarification, Lee. This helps me to understand what you guys are trying to do.
> 
> I know what you mean about some CZ patch dump data needing to be handled on a bit-by-bit basis. However, unless I am missing something I don't see any where any parameters are split up. You have some 8-bit and 16-bit [not nybblized] structures where the different bits mean different things. 
> 
> See previous message with hex, binary, and decimal explanations of (1) nybblizing and (2) reassembling the nybbles.
> 
> Also, see the files section where I posted 2 sections of C-64 assembly code showing (1) and (2) with comments added today to correlate with http://launch. groups.yahoo. com/group/ CZsynth/message/ 4111.
> 
> Also, see comments below.
> 
> --- In CZsynth@yahoogroups .com, Lee Borrell <templarser@ ...> wrote:
> >
> > Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles -
> 
> STEVE: For consistency, you might want to reassemble nyblized data first when receiving it.
> 
> > deriving the actual value of the parameter should be a matter of using Thong's table of values.
> 
> STEVE: Since Thong basically took Casio's Midi Guide book and added comments to try to explain what the graphics show in the original, I would really recommend the original. 
>  
> > Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. 
> 
> STEVE: I have used basic, but I have no idea what GFA basic is.
> 
> > I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.
> 
> STEVE: You should see Korg's EX-800/Poly- 800 packed patch data; it is all bit-wise sequential!! Does GFA Basic let you operate in hex or binary? Or is it all decimal? Did you ever work with Roland's midi data structures? It is complex, but at least they gave the address of individual parameters. I think that's what lot's of CZ/VZ users wish CAsio had done.
> 
> > I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.
> 
> STEVE: This makes sense; I just couldn't figure out why Charlie was confused by the tables. I would think a look up simple array would do it. Get the two timing bytes as an offset from the start of the array based on the display value. 
> 
> > I already have a Commodore program which creates random data for the CZ - but this is not very effective.
> 
> > I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.
> 
> > Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!
> 
> STEVE: YUP, if I understand what you mean here.
> Reassembled Byte = Nybble(1) + Nybble(2) * 2^4
> 
> > Deriving the paramters is thence a matter of masking the bits as per Thongs table.
> 
> STEVE: YUP, just so long as (1) each 8-bit structure is split/nybblized or reassembled properly and (2) you realize that PVDLD is simply the display value and PVDLV is a set of 2 8-bit values. 
> 
> Sounds like an interesting project. Let me know if I can help.
> 
> --Steve
> 
> PS: In looking at my C-64 code, I do believe the nybbles are sent and received in lsb/msb order for each 8-bit structure. Thus for a 16-but structure you would the order would be MSBlsb MSBmsb LSBlsb LSBmsb. In other words, for a Delay Time represented on the screen by = 96 (dec), the nybblized PVDLV sequence would be 2 0 15 1 (dec).
> 
> 2 + (0 *16) is the MSB 
> 15 + (1 * 16) is the LSB
> 
> In the table this appears as 60 02 1F (hex)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>       
> 
> [Non-text portions of this message have been removed]
>

I used a similar program to yours to process the PSS series.

--- On Tue, 11/8/09, steve_the_composer <smw-mail@...> wrote:

From: steve_the_composer <smw-mail@...>
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown
To: CZsynth@yahoogroups.com
Date: Tuesday, 11 August, 2009, 7:04 PM


  



Thanks for the clarification, Lee. This helps me to understand what you guys are trying to do.

I know what you mean about some CZ patch dump data needing to be handled on a bit-by-bit basis. However, unless I am missing something I don't see any where any parameters are split up. You have some 8-bit and 16-bit [not nybblized] structures where the different bits mean different things. 

See previous message with hex, binary, and decimal explanations of (1) nybblizing and (2) reassembling the nybbles.

Also, see the files section where I posted 2 sections of C-64 assembly code showing (1) and (2) with comments added today to correlate with http://launch. groups.yahoo. com/group/ CZsynth/message/ 4111.

Also, see comments below.

--- In CZsynth@yahoogroups .com, Lee Borrell <templarser@ ...> wrote:
>
> Regardless of the nybble arrangement of the CZ - once the data bytes are in place inside a PC/computer the problem is the whereabouts of the bits,which are sometimes placed across nybbles -

STEVE: For consistency, you might want to reassemble nyblized data first when receiving it.

> deriving the actual value of the parameter should be a matter of using Thong's table of values.

STEVE: Since Thong basically took Casio's Midi Guide book and added comments to try to explain what the graphics show in the original, I would really recommend the original. 
 
> Charlie and myself are trying to use GFA basic - but I am unfamiliar with this. 

STEVE: I have used basic, but I have no idea what GFA basic is.

> I have wrote programs to exploit the PSS series SYSx in Commodore basic - which worked admirably - Yamaha didn't make quite such a mess of the Sysx table and the parameters seem easier to derive.

STEVE: You should see Korg's EX-800/Poly- 800 packed patch data; it is all bit-wise sequential!! Does GFA Basic let you operate in hex or binary? Or is it all decimal? Did you ever work with Roland's midi data structures? It is complex, but at least they gave the address of individual parameters. I think that's what lot's of CZ/VZ users wish CAsio had done.

> I do not believe that we need formulae for time-wise versions of anything - only the actual decimal data from which to derive the parameters - to be edited - before sending them back to the CZ.

STEVE: This makes sense; I just couldn't figure out why Charlie was confused by the tables. I would think a look up simple array would do it. Get the two timing bytes as an offset from the start of the array based on the display value. 

> I already have a Commodore program which creates random data for the CZ - but this is not very effective.

> I think with the BYTE not over 15 - this is meaning the HALF bytes (nybbles) which of course never exceed 15 within the header and trailer bytes.

> Any given byte is therefore Nybble(1)=4 bits=15 + Nybble(2)=4 bits =15 - creating a byte of 8bits= 15+15*16 - getting them in the correct order is a must!

STEVE: YUP, if I understand what you mean here.
Reassembled Byte = Nybble(1) + Nybble(2) * 2^4

> Deriving the paramters is thence a matter of masking the bits as per Thongs table.

STEVE: YUP, just so long as (1) each 8-bit structure is split/nybblized or reassembled properly and (2) you realize that PVDLD is simply the display value and PVDLV is a set of 2 8-bit values. 

Sounds like an interesting project. Let me know if I can help.

--Steve

PS: In looking at my C-64 code, I do believe the nybbles are sent and received in lsb/msb order for each 8-bit structure. Thus for a 16-but structure you would the order would be MSBlsb MSBmsb LSBlsb LSBmsb. In other words, for a Delay Time represented on the screen by = 96 (dec), the nybblized PVDLV sequence would be 2 0 15 1 (dec).

2 + (0 *16) is the MSB 
15 + (1 * 16) is the LSB

In the table this appears as 60 02 1F (hex)

















      

[Non-text portions of this message have been removed]

If you really want to wonder about the CZ, wonder why they didn't put an F7 after each and every message in the handshake protocol. That is far more problematic from a programming point of view.


--- In CZsynth@yahoogroups.com, "charlie from PARRY" <charles.copp@...> wrote:

>
> yeah the cz101 sys ex dump differs  tremendousilly from the pss dump because
> the pss
> only shares bits in a byte value ,,
>  it outputs just the same as its read ,,
> where ,
>  now if i'm correct ,
> the cz needs divded in half  to be read
> then merged back into 256 bytes ...to be transmitted
> 
> .which has me question-ing and pondering , why?
> 
> ok the good advice always arrives at the wort time..busy doing dishes , b
> back later..
> 
>  charles
>

a good call answer handshake sends a eox  ,
i use a "check if ready for recieve" from my computer to the cz ,
this way  you'll know something is connected before trying to aquire data
with a "transmit from cz handshake"eliminating -any hangups ,

cause then you'll have to use a loop with a timer
 and do a error routine for a time out!!!..

 works either way

i wasn't really wondering about the eox after every message , thanks anyhow.
i wondered if ther was a simopler method to decipher the bytes from the raw
sys ex dump .

charles



----- Original Message -----
From: "steve_the_composer" <smw-mail@...>
To: <CZsynth@yahoogroups.com>
Sent: Wednesday, August 12, 2009 6:00 AM
Subject: [CZsynth] Re: help cz101 bytes sysex breakdown


> If you really want to wonder about the CZ, wonder why they didn't put an
F7 after each and every message in the handshake protocol. That is far more
problematic from a programming point of view.
>
>
> --- In CZsynth@yahoogroups.com, "charlie from PARRY" <charles.copp@...>
wrote:
> >
> > yeah the cz101 sys ex dump differs  tremendousilly from the pss dump
because
> > the pss
> > only shares bits in a byte value ,,
> >  it outputs just the same as its read ,,
> > where ,
> >  now if i'm correct ,
> > the cz needs divded in half  to be read
> > then merged back into 256 bytes ...to be transmitted
> >
> > .which has me question-ing and pondering , why?
> >
> > ok the good advice always arrives at the wort time..busy doing dishes ,
b

> > back later..
> >
> >  charles
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>