sysex data converteren

Enzo.F

vrijwillig lid
Lid sinds
31 mei 2010
Berichten
1.663
Locatie
a forest
Ik krijg via sysex de volgende bytes binnen als begin van een langere sysex boodschap:
Code:
F0  7E  01  00  00  0C  31  63  07  68  02  00  68  02  00  68
Ik weet dat bytes 09-11 de total words in sample representeert.
Het gaat dus om de hexadecimale getallen 68, 02 en 00 of wel in binary:
Code:
68 = 0 1 1 0   1 0 0 0
02 = 0 0 0 0   0 0 1 0
00 = 0 0 0 0   0 0 0 0

De handleiding zegt dit over de coding van deze 21 bit bytes:
Code:
TB represents a 21 bit value transmitted as three MIDI bytes:
first byte:		0	d6	d5	d4	d3	d2	d1	d0
second byte:		0	d13	d12	d11	d10	d9	d8	d7
third byte:		0	d20	d19	d18	d17	d16	d15	d14
dus ik zou de bytes die de total words in sample representeren (bits 09 t/m11) als volgt naar bits omzetten:
Code:
first byte:		0	0	0	1	0	1	1	0
second byte:		0	0	0	0	0	0	1	0
third byte:		0	0	0	0	0	0	0	0

Hoe converteer ik deze data in het cijfer dat de total words in sample representeert?
 
Deze sysex code om 3 keer 7 bit waardes te versturen.
F0 7E 01 00 00 0C 31 63 07 68 02 00 68 02 00 68

deze bytes :
68 02 00 : 7 bit hexidecimale waardes
09 10 11 : byte id

Nu is de eerste byte die binnenkomt het minst significante.

Hoe bereken je dit nu bijelkaar :

0b 0000000 0000000 0000000
meest mid minst significant

Dat maakt dus :
16384 keer het decimaal van 0x00 ( meest ) +
128 keer het decimaal van 0x02 ( mid ) +
het decimaal van 0x68 ( minst ).
 
Laatst gewijzigd:
OK! thanks, dus zoals in de manual staat:
Code:
least significant	first byte:	68
0	0	0	1		0	1	1	0
mid significant		second byte:	02
0	1	0	0		0	0	0	0
most significant	third byte:	00
0	0	0	0		0	0	0	0

Dan de decimalen van de hexadecmalen
Code:
			hex	binary			decimal
least significant	68	0 1 1 0  1 0 0 0	104
mid significant		02	0 0 0 0  0 1 0 0	  4
most significant	00	0 0 0 0  0 0 0 0	  0

Dan de rekensom:
Code:
most significant	(16384 x 0) +
mid significant		  (128 x 4) +
least significant	   (1 x 68) = 580

Is dit de uitwerking?
 
Nee,
het decimaal van 0x02 is 2
het decimaal van 0x68 is 104

totaal : 0 + 256 + 104

Nee,
het decimaal van 0x02 is 2
het decimaal van 0x68 is 104

totaal : 0 + 256 + 104

Tuurlijk! De decimaal, dom stapje vergeten!
Code:
most significant	(16384 x 0) +
mid significant		  (128 x 2) +
least significant	  (1 x 104) = 360 words
En hoe interpreteer ik de 360 words? Staat dat in verhouding tot de midi blocks van data die de sample omvatten?

Thanks tot dusver!
 
En hoe interpreteer ik de 360 words? Staat dat in verhouding tot de midi blocks van data die de sample omvatten?

Thanks tot dusver!


Kijk: wikipedia geeft raad:
Depending on how a computer is organized, word-size units may be used for:
...
Addresses
Holders for memory addresses must be of a size capable of expressing the needed range of values but not be excessively large, so often the size used is the word though it can also be a multiple or fraction of the word size.
...
 
Wat is presies het doel ?
Ga je samples via MIDI versturen ?, klinkt raar, vertel.

Het idee is om samplers die met het sample dump format van Sequential Circuits werkt de send & Receive via midi te laten verlopen. Dit zorgt ervoor dat je de QuickDisc's niet meer nodig hebt. Dit zenden en ontvangen via midi wil ik via CTRLR laten lopen.
 
Het idee is om samplers die met het sample dump format van Sequential Circuits werkt de send & Receive via midi te laten verlopen.
Wellicht is die editor voor de SCI Prophet 2000/2002 dan ook interessant voor je, misschien kun je daar nog wat extra info uithalen. Die gebruik ik nu ook om samples via MIDI naar m'n P2000 te krijgen. Werkt fijner dan floppy's.

NB. de ontwikkelaar gaf nog wel dit aan, misschien iets om rekening mee te houden bij het testen:
I had some problems with the MIDI communication with the Prophet. Sometimes some SysEx data packets are corrupted. Some of them could be restored by my software. I have got some disks which could not be transferred to the PC due to communication problems at all. I could never figure out why the communication is not working while having one of these disks loaded into the Prophet.
 
Dit is wat de midi implementatie speficcatie erover zegt:
Sample transfer is according to the standard described in the Prophet 2000 manual. This uses ‘System exclusive common’ which does not include a manufacturers prefex code. As it does not include a MIDI channel code, any samples sent, or requests for samples woudl be responded to by all samples on the same MIDI line. The ‘System exclusive common reception enable’ and ‘...disable’ messages, which do include a MIDI channel number, can be used to select one of several S700s on the same line.
 
Dit is wat de midi implementatie speficcatie erover zegt:
Sample transfer is according to the standard described in the Prophet 2000 manual. This uses ‘System exclusive common’ which does not include a manufacturers prefex code. As it does not include a MIDI channel code, any samples sent, or requests for samples woudl be responded to by all samples on the same MIDI line. The ‘System exclusive common reception enable’ and ‘...disable’ messages, which do include a MIDI channel number, can be used to select one of several S700s on the same line.
Enzo.F, dit lijkt me eerder een persoonlijke speficatie van de maker van die editor en geen standaard midi implementatie, hij heeft het dan ook over twee verschillende toestellen n.m.i. de Prophet 2000 en de S700s (Akai wss) ??? Zoja, dan toch maar uitkijken...
Zoals ik elders reeds zei : in sysex wordt geen channel-setting gebruikt, wel device setting maar dat heeft een andere functie.

P.s. Voor welk(-e) toestellen wil je nu een editor(-s) maken ?
 
Voor welk(-e) toestellen wil je nu een editor(-s) maken ?

Het gaat om de S700 van Akai. Deze machines werken met QuickDisks, spul dat niet meer werkt in vele gevallen. Als midi te gebruiken voor sending en receiving samples dan kan je makkelijk je library aan samples op de HD van je moderne computer aanleggen met behulp van een CTRLR panel.

Ik ben opzich al een eindje op weg. Zo weet ik de data uit de opgevraagde sysex te interpreteren. De words in een sample komen overeen met de sample length in de sampler. Dit maakt het ontvangen al wat voorspelbaarder. Ik kan al de request sample dump naar de sampler gooien middels een CTRLR panel.
Als ik dat met de Atari doe dan krijg ik een lange sysex message terug die wordt opgebouwd op moment dat er een ACKnowledge gestuurd wordt. Deze heeft een minmale lengte van 508 bytes (209 words in sample is het minimum)
Als ik dat met de CTRLR panel doe dan krijg ik 20 bytes terug. Op het moment dat de sample-data (block 0) zou moeten beginnen dan eindigt de sysex met een F7 (EOX).
Ik stuur exact het zelfde vanaf de Atari en vanaf het panel.

Deze is van Atari (Port 1) en S700 (Port 2) Screen Shot 2017-07-29 at 22.29.53.jpg
Wat hieraan opvalt is dat de request (6 bytes sysex) in tijd gevolgd wordt door de respons van de S700 (laatste lange sysex op Port 2, maar dat er tussendoor ook5 maal een 4 bytes sysex vanaf de Atari verzonden worden, de acknowledge package data.
attachment.php


Dit zijn de details van de Sysex-boodschap na request vanaf Atari:Screen Shot 2017-07-29 at 22.30.08.jpg
attachment.php


Dit zijn de details van de Sysex-boodschap ontvangen na request vanaf CTRLR panel:Screen Shot 2017-07-29 at 22.48.20.jpg
attachment.php
 
Laatst gewijzigd:
Enzo.F, als je wil dat mensen je CTRLR panel-ontwikkeling blijven volgen, gelieve dan één topic te gebruiken. Dat is ook makkelijker voor 'helpers' om eventueel te abonneren en alzo op de hoogte te blijven.

Ik ben opzich al een eindje op weg. Zo weet ik de data uit de opgevraagde sysex te interpreteren. De words in een sample komen overeen met de sample length in de sampler. Dit maakt het ontvangen al wat voorspelbaarder. Ik kan al de request sample dump naar de sampler gooien middels een CTRLR panel.
Als ik dat met de Atari doe dan krijg ik een lange sysex message terug die wordt opgebouwd op moment dat er een ACKnowledge gestuurd wordt. Deze heeft een minmale lengte van 508 bytes (209 words in sample is het minimum)
Als ik dat met de CTRLR panel doe dan krijg ik 20 bytes terug. Op het moment dat de sample-data (block 0) zou moeten beginnen dan eindigt de sysex met een F7 (EOX).
Ik stuur exact het zelfde vanaf de Atari en vanaf het panel.

Zonder de exacte sysestring te tonen kan ik niet met zekerheid constateren wat er gaande is.
Verder dien je die monitor in te stellen zodat de volledige sysestrings getoond worden d.w.z. van F0 t.e.m. F7, anders is de info ook niet compleet en dus correct.
Enkel de sample-dump-data zelf hoef je (nog) niet compleet in de monitor weer te geven hier.

Gelieve in je uitleg ook de exacte uitgevoerde sysexstring te tonen. Copy/Paste ze als gewone tekts i.p.v. telkens een (onscherpe) figuur van die monitor. Ik probeer met de handleiding je handelingen te volgen, maar zonder de juiste commando's gaat dat moeilijk.
Ik had elders reeds een werkwijze voorgesteld, welke ik nog steeds aanbeveel : stap 3 in deze topic
Het is wss die 'handshake' die maakt dat je een verschil in byte aantal verzonden of ontvangen krijgt.
 
Back
Top