CTRLR.org panel-ontwikkeling voor Akai S700

[Enzo.F]

Ik wil in deze draad een log bijhouden van het ontwikkelen van een CTRLR.org panel voor de Akai S700 sampler.

CTRLR.org
CTRLR.org is een applicatie waarmee panels ontwikkelt kunnen worden die middels midi hardware aansturen. Denk bijvoorbeeld aan een softwarematige programmer voor de JX8P van Roland. Middels midi-cc en midi-sysex is er bi-directionele communicatie mogelijk tussen de CTRLR software en de hardware. Panels kunnen in de CTRLR-applicatie uitgevoerd worden maar onder bepaalde omstandigheden ook worden geëxporteerd als VST.

Akai S700
De Akai S700 is een sampler uit midden jaren tachtig, een 12 bits sampler die makkelijk werkt en een intuïtieve user interface heeft maar vooral auditief karakter. Voor opslag van samples is de S700 uitgerust met een fameuze QuickDisk drive. De meeste QuickDisk-drives zijn kapot. Reparatie is duur en de capaciteit van één sample per zijde is beperkt.

CTRLR Panel voor S700
De Akai S700 biedt vanaf firmware v1.6 de mogelijkheid om middels midi de samples te ontvangen en te verzenden. Voor de Atari is er in de jaren tachtig door ene Harald Plontke een editor geschreven met uitgebreide mogelijkheden. Mijn doel is in eerste instantie om samples te ontvangen vanuit de S700 naar een CTRLR-panel en vice versa. Met gebruik van de midi-implementatie die Akai voor de S700 geschreven heeft heb ik een idee wat ik moet verzenden vanaf het panel naar de S700. De S700 antwoordt dan met sysex data.
Bekijk bijlage AkaiS700_MIDI_Implementation_V1.0.pdf

Atari communicatie
Als ik SoundSystem X700 Graphic Sample Editor op de Atari start dan zend de Atari voor elke sample geheugenplek een 8 byte sysex message naar de S700. De request for sample parameters. De S700 heeft standaard plek voor 6 samples, met de ASK70-uitbreiding kunnen er 16 samples in het geheugen van de S700 geladen worden.

Als ik vanaf de Atari vraag om sample 1 in de S700 dan zend de Atari een 6 bytes sysex message naar de S700. De request for sample dump. Er komt data vanaf de S700, maar deze verschijnt nog niet in de midi monitor. Eerst stuurt de Atari een aantal 4 byte handshakes terug naar de S700. Kijk naar de time stamp van deze handshakes en vergelijk deze met de timestamp van de respons van de S700. Uiteindelijk heeft de S700 een 508 bytes midi message naar de Atari gestuurd.

CTRLR communicatie
Als ik vanaf het CTRLR panel de zelfde 6 bytes sysex message naar de S700 stuur, de request for sample dump dan is het antwoord van de Akai S700 een 20 bytes sysex message. De eerste 19 bytes sysex message in de sample dump format zijn gegevens omtrent de sample (sample number, bitts per word, sampling period, total words, loop startpoint, loop endpoint). Zie midi implementatie document.

Probleem
Het huidige probleem waarmee ik geconfronteerd wordt is dat waarschijnlijk de handshake vanaf het CTRLR panel naar de S700 niet goed gecommuniceerd wordt. Er zal een timing probleem aan ten grondslag liggen denk ik. Als de S700 de eerste 19 bytes verzonden heeft zal het panel een 4 bytes handshake moeten sturen zodat de S700 door kan met verzenden van het eerste block sample data. Na elk blok sample data dient er ook een 4 bytes handshake verzonden te worden.

Vervolg
Na elk ontvangen block sample data zou de checksum, de laatste byte in een block sample data, moeten worden geverifieerd. Bij een mismatch is een 4 bytes "request for retransmission of last block" vanaf het panel noodzakelijk.


Bekijk bijlage 117005

 

[Designer]

Sysex van 580 bytes lijkt mij onmogelijk dat je klok nog goed loopt.
Commandos moeten zo kort mogelijk wezen, het liefst voor elke sampleframe 1 commando.

Vergeet het maar zou ik zeggen, als je tog verder wilt, regel dan een logic anylizer of oscilloscope waarmee je naar dit kunt kijken.

 

[audiocollage]

... Als ik vanaf de Atari vraag om sample 1 in de S700 dan zend de Atari een 6 bytes sysex message naar de S700. De request for sample dump. Er komt data vanaf de S700, maar deze verschijnt nog niet in de midi monitor. Eerst stuurt de Atari een aantal 4 byte handshakes terug naar de S700.

Enzo.F ... om een beetje in jou stijl van werken verder te gaan (daar je tips en antwoorden weinig respecteerd) : "gooi er eens een ander monitortje op".

Sysex van 580 bytes lijkt mij onmogelijk dat je klok nog goed loopt....

Designer sysexstrings van enkele kilobytes zijn voor veel apparatuur geen probleem. Onderzoek eens wat patches van synthesizers and you'll see.

 

[Enzo.F]

Uit de source code van de Atari software haal ik het volgende met betrekking tot de sample dump request. Ik ben geen expert in deze programmeertaal maar ik zie dat er hier en daar een pauze is ingelast en dat er een handshake wordt gestuurd na de 18e byte.

FUNCTION mdl_sample_exc(startword%)
  LOCAL ptr%,testlen%
  ptr%=@sampleptr(startword%)
  mds_rsd(smpnr&) ! Request Sample Dump
  PAUSE 5
  '
  mdl_wait(&HF0) ! SAMPLE HEADER
  mdl_wait(&H7E)
  mdl_wait(1)
  ~@mdl_b         ! Smpnr
  ~@mdl_b         ! reserved
  mdl_wait(12)
  smpprd%=@mdl_tb ! Samplingperiod 3 Byte
  len%=@mdl_tb    ! Samplel„nge
  istlen%=len%*2
  d1%=@mdl_tb     ! Loopoint
  d2%=@mdl_tb     ! Endpoint
  d3%=@mdl_b      ! Replay mode
  [COLOR="Red"]mds_acks[/COLOR]
  PAUSE 5
  IF status%=0
    PRINT AT(52,1);"Data >"
    REPEAT
      cnt%=0
      REPEAT ! Blocknummer oder EOX
        IF BIOS(1,3)
          d%=BYTE(BIOS(2,3))
          GOTO mdl_s700_out1
        ENDIF
        INC cnt%
      UNTIL cnt%>200
      midierror
      '
    mdl_s700_out1:
      EXIT IF d%=&HF7 OR status%<>0
      checksum%=0
      x%=0
      REPEAT
        '
        cnt%=0
        REPEAT
          IF BIOS(1,3)
            d%=BYTE(BIOS(2,3))
            IF testlen%<=istlen%
              POKE ptr%,d%
            ENDIF
            INC ptr%
            INC testlen%
            INC x%
            GOTO mdl_s700_out2
          ENDIF
          INC cnt%
        UNTIL cnt%>200
        midierror
        '
      mdl_s700_out2:
      UNTIL x%=120 OR status%<>0 OR d%=&HF7
      '
      EXIT IF d%=&HF7 OR status%<>0
      PRINT AT(58,1);(ptr%-sampleptr%(sample&)) DIV 2
      chs%=@mdl_b   ! Checksum
      mds_acks
    UNTIL status%<>0
  ENDIF
  PRINT AT(52,1);"             "
  RETURN len%
ENDFUNC

Voor wat betreft jouw geadviseerde stappen in deze post; daar geef ik hier antwoord op en ik weet wat ik zend en ik weet wat ik ontvang.

Waar ik niet uitkom is het exacte moment vinden van het verzenden van de ACK handshake. Dit zal na de 'scan mode' byte (in de source code hierboven "replay mode" genaamd) moeten gebeuren volgens de source code van de Atari software. Ik neem aan dat ik dit in LUA / Ctrlr moet gaan organiseren. Ik ben in ieder geval al weer een stukje verder!
Thanks Audiocollage!

 

[audiocollage]

... Voor wat betreft jouw geadviseerde stappen in deze post; daar geef ik hier antwoord op en ik weet wat ik zend en ik weet wat ik ontvang.

Het gaat niet om je antwoord op mijn tips, ik weet zelf wel waarom ik die tips geef, het gaat om de resultaten die jij krijgt bij uitvoer ervan.
Veel toestellen kunnen makkelijk enkele kilobytes probleemloos verzenden en kunnen dan ook werken zonder 'handshake'.

Verder is die code n.m.i. alles behalve compleet (Wat ik nog herinner van GFA, voilà nu weet je ook al welke programmeertaal het is.)
Zover ik nog herinner zijn dit ook allemaal functies die erbij horen : mdl_wait(), @mdl_tb, @sampleptr(), mds_rsd().
Bovendien worden daar ook nog enkele hardware functies aangesproken, die moet je wel degelijk kennen om te weten wat ze doen.
Dus ... leer maar eerst GFA analyzeren en dan LUA programmeren. Of probeer gewoon die tip die ik reeds gaf.

 

[Designer]

Je zal wel gelijk hebben Enzo,
ik zal eens wat uitzoeken hoe het presies werkt en neem mijn commentaar terug.

 

[Enzo.F]

Je zal wel gelijk hebben Enzo,
ik zal eens wat uitzoeken hoe het presies werkt en neem mijn commentaar terug.

Midi Sysex is anders dan general midi (voor aansturing van muzieknotatie) en continuos control (midi CC).

Geen probleem, Designer, fijn dat je meedenkt!

 

[Enzo.F]

Progression is made!
Het panel kan nu een request om sample dump voor een bepaalde sample in het geheugen van de S700 uitzenden. De S700 antwoordt dan naar het panel en de eerste 20 sysex bytes komen goed aan en die worden geïnterpreteerd en naar output fields op het panel gestuurd. Zie bijlagen.

Het gaat er vervolgens om dat ik op de door de S700 verwachte momenten de acknowledge sysex terug stuur zodat de S700 niet na 19 bytes de EOX stuurt maar doorgaat met de verzending van de volgende package bytes. Wordt vervolgd...

@audiocollage
de source van GFA (copyright Harald Plontke) is ter indicatie en niet een leidraad. Ik weet wat er bi-directioneel gecommuniceerd wordt via sysex. De diverse midi-monitoren die ik gebruik geven allen de zelfde bytes weer. SNoize, CTRLR midi monitor en anderen, het komt overeen met wat de diverse midi-implementatie documenten uit die tijd van Akai. Thanks voor het meedenken en vooral uitleggen!

 

[audiocollage]

Volgens je handleiding, zoals hieronder weergegeven, zou je geen EOX mogen ontvangen na die request for sample dump, dus waar exact ontvang jij die EOX ?
Heb je die handleiding juist overgeschreven of werkt je Akai nog wel goed, ik heb daar alzo geen zicht op.
Ook niet op hoe en waar de grootte van sample blocks die de Akai uitstuurd, worden bepaald ?

EXAMPLE OF DIALOG WHERE COMPUTER RECEIVES SAMPLE FROM S700

COMPUTER: RSD
(0F0H, 7EH, 0, 0, 0, 0F7H)
Computer requests S700 to send its first sample.

S700: SD
(0F0H, 7EH, 1, 0, 0, 0CH,
77H, 27H, 2, Sample period – 10^9 / 26400.
79H, 7FH, 1, Words in sample = 32752.
34H, 7FH, 1, Loop start point = 32692.
77H, 27H,2, Loop end point = last sample
point
0) Mode=looping.

*****hier staat geen EOX en dus zou de AKAI in een soort wachtmodus moeten komen te staan om de ACK te ontvangen****

COMPUTER: ACKS
(0F0H, 7EH, 7FH, 0F7H) Computer acknowledges sample
header.

S700: (0, 40H, 0, 40H, 0, 40H, 0, 40H, 0, …… 0)
This is a block of 60 sample points.

COMPUTER: ACKS
(0f0h, 7EH, 7FM, 0F7H) Computer acknowledges
sample
block.

The above two lines are repeated while S700 sends a total of 546
blocks.
:
:
:
S700: (26H, 40H, 0, 40H, 0, 40H, 0, 40H, 0, ……0, 0,
0, 0, 0)
This is the 546th block. Note that the last bytes are padde
with 0s to keep the block the same length as the others.

COMPUTER: ACKS
(0F0H, 7EH, 7FH, 0F7H) Computer acknowledges
last
block.

S700: EOX
(0F0H) Marks end of message.

 

[Enzo.F]

Als ik vanaf de Atari een

0F0H 7EH 0 0 0 0F7

(Request for sample dump) stuur dan gaat ie (de sampler) wel door met verzenden van de sample data blocks.
En ik zie dan ook een ACK vanaf de Atari komen.
Zie deze afbeelding waarin port1 de Atari is en port 2 de sampler.

Ik zie geen pauze via sysex verzonden worden. Wellicht regelt de software dat, maar hoe?

 

[audiocollage]

...Ik zie geen pauze via sysex verzonden worden. Wellicht regelt de software dat, maar hoe?

Een pauze is gewoon een wachttijd, geen sysexcommando.
De Akai 'hardware' zelf stopt even.
Een request is een aanvraag voor een dump vanuit de Akai en niet naar de Akai.

Uit je handleiding :

A further enhancement of the standard sample dump protocol is
that when closed loop transmission is used, gaps between blocks may
be as long as 10 seconds rather than the 20 mS specified. This allows
the computer to use its disk in the middle of a long file. This
variation maintains full compatibility with the standard.

Bovendien is het ongebruilkelijk om 5 maal een ACK te verzenden voordat er ook maar enige data ontvangen werd.
Waarom gebeurt dat ?

En als de Atari toch dat ongebruikelijke doet, doe jij het dan ook in CTRL en zie wat dat geeft, zou ik zeggen...

 

[Enzo.F]

Bovendien is het ongebruilkelijk om 5 maal een ACK te verzenden voordat er ook maar enige data ontvangen werd.
Waarom gebeurt dat ?

En als de Atari toch dat ongebruikelijke doet, doe jij het dan ook in CTRL en zie wat dat geeft, zou ik zeggen...

Als je naar de time stamp (sorry voor de verkeerde notatie) kijkt zie je dat het antwoord ouder is dan de vijf ACK messages. Dus het eerste deel, de eerste 19 bytes zijn verzonden, dan ontvangt de sampler de eerste ACK. Dus het zijn reacties op ontvangst.

 

[Enzo.F]

Het lukt me nu om middels willekeurige acknowledge-sysex berichten een hele sample binnen te krijgen. Dat is goed nieuws! Ik moet alleen eigenlijk wat treffender de ack-messages kunnen sturen. Punt is dat CTRLR voor alsnog niet instaat is om de hoeveelheid binnengekomen midi-sysex bytes te evalueren. Dat gebeurt pas nadat de sysex boodschap helemaal binnen is. Soit, met de binnengekregen info kan ik al uit de voeten. Heb met de Atari gecheckt of de grote ook klopt met de door de Atari ontvangen sysex. Dat is het geval. Ik heb ook een sample tot mijn beschikking, dat gaat ervoor zorgen dat ik weet hoe de samples worden opgeslagen. Met of zonder de parameters. Interessant interessant!

To be updated!