atari

[Usoulmusiq]

heey, ik heb een atari 1040 stf, een normale computer en een roland mpu-ipc-t.
ik heb mijn atari op mijn computer aangesloten via mijn roland en ik vraag me af of ik een bulk dump kan doen van samples door de midi kabel.
ik weet dat de atari weinig geheugen heeft maar ik heb een externe harddisk aangesloten
kan ik dan ook mijn atari sequencen via mijn computer?

 

[6 trak]

nou, data via een midikabel verzenden gaat met max. 3 kb/sec (zo'n 10,5mb/ uur) dus succes!

 

[dubcreator]

Atari zou je kunnen syncen met de PC. Ik zou het alleen wel andersom doen. Atari als master gebruiken. En idd de samples... veel succes. Maar voorzover ik weet doet de atari niet aan audio en zou ik samples lekker in de PC doen.

 

[6 trak]

Maar voorzover ik weet doet de atari niet aan audio en zou ik samples lekker in de PC doen.

niet in afspeelbare audio idd maar je zou wel sample data kunnen bulkdumpen nutuulk...

 

[Niel]

niet in afspeelbare audio idd maar je zou wel sample data kunnen bulkdumpen nutuulk...

hoho, ik heb ooit een 2e atari gebruikt met een audio cartidge met tulpjes erop.
Goedkoop een 1 mb sampler !

zie: https://www.synthforum.nl/forums/showpost.php?p=964244&postcount=8

ontopic: Waarom zou je de atari willen sequencen met je pc als hij niks anders doet dan zelf sequencen ?
Dan kan je net zo goed de pc sequencer direct aan je roland hangen via midi.
Idem voor de sample dump.

 

[6 trak]

hoho, ik heb ooit een 2e atari gebruikt met een audio cartidge met tulpjes erop.
Goedkoop een 1 mb sampler !

jawel maar dat werd er niet bedoeld nutuulk...

 

[audiocollage]

nou, data via een midikabel verzenden gaat met max. 3 kb/sec (zo'n 10,5mb/ uur) dus succes!

Klopt dat wel 6 trak ?
Midi gaat toch met een snelheid van 31.250 baud dat is dan toch eerder 30 kb/sec (zo'n 105mb/ uur dan) of vergis ik me.
Bovendien is die 31.250 baud eigenlijk de clocksnelheid voor registratie van midi data in DAW's en dus hoeft n.m.i. zo'n bulk dump
tussen twee computers daar niet direct rekening mee te houden.
Nou ja dat is mijn idee, ik zou dat graag in praktijk eens testen.

(Er was ook nog de Atari Falcon... betreft die audio)

 

[neuromancer]

@audiocollage: 31.250 bits/sec dus nog delen door 8 is ongeveer 4 kb/sec

 

[etaoin]

Klopt dat wel 6 trak ?
Midi gaat toch met een snelheid van 31.250 baud dat is dan toch eerder 30 kb/sec (zo'n 105mb/ uur dan) of vergis ik me.

Ik vermoed dat 6 sowieso kB bedoelde ipv kb.
MIDI is meen ik 1 start bit en 1 stop bit? Dus 31250 baud is dan ongeveer 25kbit per seconde, waarbij MIDI ook nog eens maar 7 van de 8 bits gebruikt voor data, dus ongeveer 2700 bytes per seconde in de optimale situatie (grote geoptimaliseerde SysEx met weinig overhead). Dat is 9,8MB per uur.

Bovendien is die 31.250 baud eigenlijk de clocksnelheid voor registratie van midi data in DAW's en dus hoeft n.m.i. zo'n bulk dump tussen twee computers daar niet direct rekening mee te houden.

Die 31250 heeft weinig van doen met de registratie in een DAW. Juist DAW's kunnen veel sneller. Maar veel seriële hardware in midi interfaces draait op een vaste klok (1 MHz / 32 of een variant daarvan, daar komt die datarate ook vandaan), nog even los van dat het ook afhangt van de kwaliteit van de opto-coupler e.d. hoe snel daar data maximaal doorheen kan.

Buiten de spec om kan het inderdaad veel sneller, zoals de 1 MHz midi bus die OMS aan kon.

 

[audiocollage]

Ik vermoed dat 6 sowieso kB bedoelde ipv kb.
MIDI is meen ik 1 start bit en 1 stop bit? Dus 31250 baud is dan ongeveer 25kbit per seconde, waarbij MIDI ook nog eens maar 7 van de 8 bits gebruikt voor data, dus ongeveer 2700 bytes per seconde in de optimale situatie (grote geoptimaliseerde SysEx met weinig overhead). Dat is 9,8MB per uur.

B en b maken inderdaad al een verschil van 8 maal.
Die start en stop bit... hmmm, in geen enkele midi data ben ik die al ooit tegengekomen. Ook niet bij gebruik van de low-level-midi commando's zoals gebruikt in vele DAW's. Ik dacht me te herinneren dat in die baud-term reeds een foutmarge ingecalculeerd is, welke met moderne apparatuur haast niet meer voorkomt. Worden die 31250 baud dan niet werkelijk 31250 bits ?
Verder gebruikt midi toch wel degelijk een volledige byte i.p.v. 7 bits. Alleen zijn de variable waarden voornamelijk onder de 128 en dus met 7 bits te omschrijven, de 8-ste bit wordt meer gebruikt bij het omschrijven van het type commando.

Die 31250 heeft weinig van doen met de registratie in een DAW. Juist DAW's kunnen veel sneller. Maar veel seriële hardware in midi interfaces draait op een vaste klok (1 MHz / 32 of een variant daarvan, daar komt die datarate ook vandaan), nog even los van dat het ook afhangt van de kwaliteit van de opto-coupler e.d. hoe snel daar data maximaal doorheen kan...

Ja dat lijkt me juister, enkel bij communicatie tussen midi hardware onderling (die UART's).
Nog wel opmerken dat het alom geprezen OS (MS) geen snellere clock-registratie toelaat dan 1/1000 seconde.

 

[etaoin]

Die start en stop bit... hmmm, in geen enkele midi data ben ik die al ooit tegengekomen.

Die zitten ook niet in de midi data maar in het onderliggende protocol. Jij kijkt op het data niveau, maar ik heb het over het seriële protocol dat de UARTs daadwerkelijk met elkaar praten, want dat is van belang voor de daadwerkelijke doorvoersnelheid. En dat is 8N1.

Die start en stop bits kosten ook ruimte binnen die 31.250 clocks, vandaar dat je niet moet delen door 8 voor het aantal bytes, maar door 10.

Dus 3.125 bytes per seconde aan ruwe data. Maar ook binnen SysEx zijn de data 'bytes' maar 7 bit. Normale midi data houdt daar rekening mee, maar als we het hebben over samples (want daar gaat het hier over), is de SysEx in z'n meest efficiënte vorm dus minimaal 8/7 groter dan het origineel.

 

[6 trak]

Ik vermoed dat 6 sowieso kB bedoelde ipv kb.

ik bedoel kilobytes... idd...

MIDI is meen ik 1 start bit en 1 stop bit? Dus 31250 baud is dan ongeveer 25kbit per seconde, waarbij MIDI ook nog eens maar 7 van de 8 bits gebruikt voor data, dus ongeveer 2700 bytes per seconde in de optimale situatie (grote geoptimaliseerde SysEx met weinig overhead). Dat is 9,8MB per uur.

maar er word nutuulk nog wel steeds de volle byte transmitted,
tenzij je het slechts hebt over de daadwerkelijk sample data dan kom je idd op een ander getal uit...
ik ging dus gemakshalve ff uit van max 1000 Note-ONs/sec, ofterwijl 3000 bytes/sec dus...

maar anyway; grote hoeveelheden sample data versturen over een MIDI kabel is gewoon niet erg done

 

[etaoin]

maar er word nutuulk nog wel steeds de volle byte transmitted

Niet als het een SysEx dump is. Hoe het werkt bij SDS weet ik eigenlijk niet. Gebruikt die wel de volle 8 bits?

[edit]
Opgezocht:

Each data byte hold seven bits, with the msb in each byte set to 0, in order to conform to the requirements of MIDI data transmission. Information is left justified within the 7-bit bytes, and unused bits are filled with 0.

Een 16-bits sample wordt in SDS verstuurd als 3 midi data 'bytes'. Dus nog minder efficiënt dan 8/7.

 

[6 trak]

mja ok, maar conclusie is gewoon dat je via MIDI geen tientallen MB's moet gaan zitten pompen

 

[etaoin]

Nee dat sowieso niet

 

[neuromancer]

Ik gebruik midi altijd om blu-ray images van het internet te downloaden.....

Nee....wel gebruikt om sampledumps van/naar m'n S550 sampler te doen..en daar duurde het echt wel lang.
Op een mirage is het met 2x 64kb nog wel te doen

 

[audiocollage]

...Maar ook binnen SysEx zijn de data 'bytes' maar 7 bit. Normale midi data houdt daar rekening mee, maar als we het hebben over samples (want daar gaat het hier over), is de SysEx in z'n meest efficiënte vorm dus minimaal 8/7 groter dan het origineel.

F0 en F7 zijn de begin- en eind-byte van elke sysexstring en die kun je niet met 7 bits formuleren...
Een sysexstring uitlezen gebeurt ook byte per byte en niet met 7 bits.
[EDIT](ooops "jij kijkt op het data niveau" ... 'k bleef effe steken)[EDIT]

Maar wat ik interessanter vind is die 1 MHz / 32 clock voor die UART"s.
Ik dacht dat er interfaces waren waarop, met sysex-commando's of dat onderliggende protocol, hogere clock-snelheden kunnen ingesteld worden, speciaal voor sample-dumps.

 

[etaoin]

F0 en F7 zijn de begin- en eind-byte van elke sysexstring en die kun je niet met 7 bits formuleren...
Een sysexstring uitlezen gebeurt ook byte per byte en niet met 7 bits.

Daarom zeg ik ook "binnen de SysEx", oftewel alles tussen die F0 en F7. Midi data bytes hebben het MSB altijd 0. Ik zeg nergens dat midi data zelf 7-bit is (integendeel, ik noem 8N1 hierboven; start - 8bit - no parity - stop).

En met 8/7 bedoel ik dat je in het meeste efficiënte geval van alle bytes in de sample dump een bit stript om het binnen die 7-bit beperking te krijgen en die bits dan verdeelt over extra data-bytes. Maar na nalezen van de SDS specificatie blijkt dat ze dat helemaal niet eens doen en gewoon drie bytes gebruiken om een 16-bit sample te versturen. Oftewel je krijgt zelfs maar 2/3 van de hoeveelheid data erdooor via SDS omdat er een hoop loze bits verstuurd worden.

Ik dacht dat er interfaces waren waarop, met sysex-commando's of dat onderliggende protocol, hogere clock-snelheden kunnen ingesteld worden, speciaal voor sample-dumps.

Dat zou goed kunnen. Als je die UART een hogere clock aanbiedt gaat de data sneller. Als dat aan beide kanten gebeurt kan de data sneller over de lijn (binnen de beperkingen van een niet afgeschermde current loop en cheapo opto-couplers natuurlijk...). Ik ben ook wel benieuwd of dat soort interfaces inderdaad bestaan (of bestaan hebben).

 

[etaoin]

Maar realistisch gezien...

De Atari heeft een PC900 optocoupler die een totale schakeltijd (onder normale omstandigheden) heeft van 3µs. Dus heel veel sneller dan iets van 300kHz gaat het sowieso niet worden... Toegegeven, da's al 10 keer sneller dan gewoon midi, maar zoals 6 trak zegt, vele megabyten zou ik er niet overheen zetten...

 

[audiocollage]

Dan blijft het enkel nog interessant te weten 'of en hoe' die hogere clock-snelheden gezet zouden kunnen worden (softwarematig).
Ik dacht dat Yamaha daar ooit iets rond gedaan had (vooraf aan die mLan e.d.).