midi channel latency

Dat hangt maar net van je sequencer af. Sommige sequencers versturen noten op een lager kanaalnummer met een hogere prioriteit. Hierdoor heeft kanaal 1 een lagere latency. Er zijn trouwens ook sequencers die juist kanaal 10 de hoogste prioriteit geven omdat dat het drumkanaal is.
 
Ook de midi implementatie op je synth speelt een rol.
Maar goed dat ik veel monofone synths heb, heb je al deze 'problemen' niet. :)
 
De context was hier software sequencers. Ik neem aan dat deze niet kanaal 10 voortrekken.

Een kort voorbeeldje van wat voor subroutine er in zo'n programma zou kunnen zitten.

for(i=1;i==16;i++){
if midi(i)!=null{
send_midi(i);
}
}

Hij begint dus bij kanaal 1 met tellen. En stel dat verzenden 20 nano seconden duurt dan ben je bij kanaal 10 al 200 nanoseconden dus 0.2 ms verder. (dit zijn allemaal aannames maar zal er niet ver naast zitten)

Midi is een serieel protocol (76kbit/s) en daar hoort dus ook de nodige overhead bij en dus extra vertraging.

Dus kanaal 1 is sneller en hierbij valt dan ook nog op te merken dat alle kanalen nooit 100% dezelfde tijd hun informatie kunnen verzenden en ontvangen. (zelfs niet met een Atari)

En bij een sample frequentie van 44.1khz zijn dat bijna 9 samples. En kun je bij frequenties hoger dan 5khz je al phase cancellation krijgen als je pech hebt of in ieder geval klinkt het anders. Er is overigens weinig wat je er aan kan doen behalve dan een zo goede mogelijke midicontroller te gebruiken met per apparaat aparte midiaansluitingen of helemaal geen midi gebruiken.

Vroeger was er een opvolgende kandidaat van midi nl. midi2 en die was 10x zo snel. Daarvan is de vertraging dan nog veel minder. En bij varianten van virtuele midi via mLan zal deze vertraging nog veel minder zijn omdat je dan snelheden kunt bereiken die 100Mbit/s zijn. (factor 1000)

En duidelijke voordelen hiervan zijn dus dat je naast note on/off informatie je ook aftertouch en andere controllers (bijna) ongelimiteerd kunt gebruiken zonder dat je timingproblemen krijgt als bij de huidige midi standaard.

En dat ze na 20 jaar nog steeds niet die midi standaard willen upgraden vind ik dus vette onzin want het is een en al politiek wat al die fabrikanten tegenhoud om betere produkten aan hun klanten te kunnen verkopen.

Sterker nog als je sample nauwkeurige midi wilt hebben dan zul je met je midi informatie timing informatie extra moeten bijvoegen zodat het niet afhankelijk is van snelheden van computers,apparaten,midi controllers en lengte van midi kabels ed. Voor digitale IO heb je iets wat er op lijkt nl. de wordclock, maar dat is meer een soort metronoom die alle IO sync'ed.
 
Orgineel geplaatst door fuse
Hij begint dus bij kanaal 1 met tellen. En stel dat verzenden 20 nano seconden duurt dan ben je bij kanaal 10 al 200 nanoseconden dus 0.2 ms verder. (

En de oplossing: .... Steinberg Midex8 , (Cubase-users) of Emagic AMT8 (Logic). De ingebouwde technologie zorgt ervoor dat alle data op het juiste moment wordt afgegeven. Gevolg is retestrakke timing. :-)

Het is natuurlijk lichtelijk debiel, dat wij in 2002 nog steeds werken met een twintig jaar oud protocol. Als je PC drie jaar oud is, lijkt hij al antiek, laat staan twintig.

mLan heeft denk ik de toekomst.
 
Orgineel geplaatst door Cozko


Het is natuurlijk lichtelijk debiel, dat wij in 2002 nog steeds werken met een twintig jaar oud protocol. Als je PC drie jaar oud is, lijkt hij al antiek, laat staan twintig.

Ongeveer net zo debiel als de liefde van velen voor synths en drumkastjes van 20 jaar oud?
Als iets goed is en voor jou werkt, waarom t dan veranderen. En bovendien, ik kijk nu al op tegen al t midi-->m-Lan converter geweld....baah
 
Orgineel geplaatst door Cozko

En de oplossing: .... Steinberg Midex8 , (Cubase-users) of Emagic AMT8 (Logic). De ingebouwde technologie zorgt ervoor dat alle data op het juiste moment wordt afgegeven. Gevolg is retestrakke timing. :-)

Denk niet dat de oplossing die jij hier aandraagt het probleem oplost. Het ligt nl. aan het midi protocol zelf niet aan wat voor een hardware dit afhandeld. Wel wat de midex8, AMT/Unitor doen is voor alle 8 midi outputs alles syncen. Maar dus niet per midikanaal omdat dit simpelweg niet kan.


Orgineel geplaatst door Cozko

mLan heeft denk ik de toekomst.

Hang er helemaal vanaf hoever het ondersteund gaat worden door de industrie.
 
Orgineel geplaatst door Pjotr G
Ongeveer net zo debiel als de liefde van velen voor synths en drumkastjes van 20 jaar oud?

Dat lijkt me iets totaal anders. Ik rijd persoonlijk liever in een mooie 30 jaar oude klassieker dan in een verrotte Opel Kadett uit 1984. :-)

Als iets goed is en voor jou werkt, waarom t dan veranderen. [/B]


Als het goed werkt, moet je het dus niet veranderen!
 
Orgineel geplaatst door fuse
Denk niet dat de oplossing die jij hier aandraagt het probleem oplost. Het ligt nl. aan het midi protocol zelf niet

De echte oplossing is natuurlijk een nieuw protocol. Daar zijn we het uiteraard helemaal over eens. Maar zolang dat niet voorhanden is, lijkt me dit een prima manier van behelpen. :)

In ieder geval kan de Midex/AMT timing concurreren met de befaamde hardware sequencers. Da's al heel wat. Tuurlijk moet je die dingen niet al te zeer overdrijven. Er is ook veel 'puristische' bull-shit bij.

Van mLan weet ik het natuurlijk ook niet het dè standaard gaat worden. Het lijkt me nog wat duur. Maar als Yamaha (en dus ook KORG) het er doorkrijgen, gaan de anderen vast wel mee.
Firewire (soort van basis van mLan) is toch ook wel erg interessant voor midi en audio. Firewire is wel een behoorlijke standaard aan het worden. In ieder geval beter/sneller dan USB! Ik denk dat we het over een jaar wel weten :D
 
Laatst gewijzigd:
Over een paar daagjes is er de winter NAMM en ik had al gehoord dat Yamaha met iets op de proppen zou komen.

En dan heb ik het niet over die PS120.

Maarja rumours are rumours
 
Je kan trouwens midi timing ook verbeteren door ervoor te zorgen dat je op het begin van een tel niet 20 note-on berichten uitzend. Als je stringetjes en andere 'trage' geluiden iets eerder of later timed dan zullen je drumgeluiden strakker lopen. Control changes die tegelijk vallen met je drumgeluiden kun je vaak ook wat opschuiven zonder dat dat hoorbaar is.
 
Orgineel geplaatst door fuse
De context was hier software sequencers. Ik neem aan dat deze niet kanaal 10 voortrekken.

Okee, het ging dus om een aanname.

Een kort voorbeeldje van wat voor subroutine er in zo'n programma zou kunnen zitten.

for(i=1;i==16;i++){
if midi(i)!=null{
send_midi(i);
}
}

Hij begint dus bij kanaal 1 met tellen. En stel dat verzenden 20 nano seconden duurt dan ben je bij kanaal 10 al 200 nanoseconden dus 0.2 ms verder. (dit zijn allemaal aannames maar zal er niet ver naast zitten)


200 nanoseconde = 0,2 microseconde. Een microseconde is 1000x zo klein als een milliseconde.

Midi is een serieel protocol (76kbit/s) en daar hoort dus ook de nodige overhead bij en dus extra vertraging.

MIDI heeft een baudrate van 31.250 bits per seconde en is inderdaad een serieel protocol. Om serieel een byte (8 bits) te verzenden zijn er een start- en een stop-bit nodig. Voor elke byte die je verzend, ben je dus bij elkaar steeds 10 bits kwijt. Daardoor kun je met MIDI dus maximaal 3125 bytes per seconde versturen. Een Note On/Off bericht in MIDI bestaat normaal gesproken uit 3 bytes. Dat betekent dus, dat je maximaal 1041 (afgerond) Note On/Off berichten per seconde kunt versturen. Omgerekend is dit 1 Note On/Off bericht per 0,96 milliseconde.

Ook al zou de sequencer 0,2 milliseconde nodig hebben om een MIDI bericht in elkaar te zetten en versturen, de sequencer heeft voor het versturen tijd genoeg, want hij kan maar 1 bericht in 0,96 milliseconde versturen. MIDI latency wordt vrij vaak veroorzaakt door de laag gekozen snelheid van het MIDI protocol. De snelheid van de sequencer is dus niet zo erg van belang, wel de volgorde waarin de sequencer de berichten verstuurt.

Dus kanaal 1 is sneller en hierbij valt dan ook nog op te merken dat alle kanalen nooit 100% dezelfde tijd hun informatie kunnen verzenden en ontvangen. (zelfs niet met een Atari)

Als je de situatie hebt, waarbij je een sequencer 'gelijktijdig' een Note On bericht laat versturen naar alle 16 MIDI kanalen van 1 MIDI Out poort en je gaat ervan uit, dat de sequencer begint te tellen bij kanaal 1, dan zal er een vertraging onstaan tussen kanaal 1 en kanaal 16 van 14,4 milliseconde. Als je er verder van uitgaat, dat het menselijk oor een vertraging kan waarnemen van minimaal 10 milliseconde, dan kun je inderdaad het verschil horen in timing tussen kanaal 1 en 16.

Of een sequencer altijd bij kanaal 1 begint en zo doorloopt naar kanaal 16, dat blijft de vraag. Ik zal het zo eens testen met m'n Atari als zender en m'n PC met MIDIOX als ontvanger om de volgorde te bekijken van de berichten.

En bij een sample frequentie van 44.1khz zijn dat bijna 9 samples. En kun je bij frequenties hoger dan 5khz je al phase cancellation krijgen als je pech hebt of in ieder geval klinkt het anders. Er is overigens weinig wat je er aan kan doen behalve dan een zo goede mogelijke midicontroller te gebruiken met per apparaat aparte midiaansluitingen of helemaal geen midi gebruiken.

Als je met MIDI werkt, zou ik me niet al te druk maken over phase cancellation. Als je weinig MIDI latency wilt hebben, dan is inderdaad het gebruik van een sequencer interface met verschillende MIDI poorten aan te raden. Hierdoor krijg je te maken met de veel kleinere latency tussen de interface en de sequencer. Het beste is om per synth een eigen MIDI poort beschikbaar te hebben.

Sterker nog als je sample nauwkeurige midi wilt hebben dan zul je met je midi informatie timing informatie extra moeten bijvoegen zodat het niet afhankelijk is van snelheden van computers,apparaten,midi controllers en lengte van midi kabels ed. Voor digitale IO heb je iets wat er op lijkt nl. de wordclock, maar dat is meer een soort metronoom die alle IO sync'ed.

De lengte van een MIDI kabel heeft weinig te maken met MIDI timing, maar meer met de kwaliteit van de MIDI berichten. Als een MIDI kabel langer is dan zo'n 15 meter, dan zal de kwaliteit van een bericht, dat over deze kabel verstuurd wordt zodanig verslechteren, dat een MIDI bericht moeilijk leesbaar wordt voor de ontvanger.

Het doorlussen van MIDI kabels via de MIDI Thru poort van een apparaat kan wel voor timing problemen zorgen. De elektronica, die het MIDI In signaal doorlussen naar de MIDI Thru poort zorgen voor een zekere vertraging, maar zorgen er daarnaast wel voor, dat MIDI berichten goed leesbaar blijven voor de ontvanger, die aan de MIDI Thru poort gekoppeld zit.

Zo en dan nu een Bavaria... :)
 
Laatst gewijzigd:
Orgineel geplaatst door fuse
Denk niet dat de oplossing die jij hier aandraagt het probleem oplost. Het ligt nl. aan het midi protocol zelf niet aan wat voor een hardware dit afhandeld. Wel wat de midex8, AMT/Unitor doen is voor alle 8 midi outputs alles syncen. Maar dus niet per midikanaal omdat dit simpelweg niet kan.

Cozko heeft gelijk. Een computer kan sneller een MIDI poort van een interface aansturen dan dat het MIDI protocol verschillende MIDI kanalen kan benaderen. Gebruik voor betere MIDI timing dus per synth een eigen MIDI poort van zo'n interface en gebruik zo weinig mogelijk de MIDI kanalen per poort.
 
Ja hoor, eerst vragen en dan later zelf het antwoord zo precies geven alsof het lijkt dat je heel slim bent. Mooi is dat! ;)

Maar eh, kloppen doet het wel he van die vertraging?

Trouwens is het ook nog eens zo dat bij midi keyboards ze een constant keep alive signaal uitsturen zodat de ontvangende kant (sequecer) snel genoeg kan reageren mocht er ooit een keer een note on bericht aankomen.

En mocht je via midi time code apparaten aan elkaar willen knopen is het aan te raden om ook weer een aparte midi lijn te gebruiken omdat tussen al dat time code geweld de timing van note on/off ook nog wel eens tegen kan vallen. Soms kan dit niet maar apparaten dat als MTC slave kunnen optreden hebben meestal ook een eigen sequencer en die zou je dan kunnen gebruiken om je note on/off commando's te sequencen.
(Waarom ik nog niet midi-b van m'n EX5 heb aangesloten snap ik zelf ook nog niet, zal wel iets met midi kabels te maken hebben)

Trouwens even heel iets anders. We lopen hier wel over ms en wat al niet meer te vozen, maar ik houd mezelf niet voor dat ik zo strak kan spelen binnen de paar ms hoor. Denk dat je eerder in de buurt van 10'en van ms komt als je helemaal nuchter bent.
 
Orgineel geplaatst door fuse
Ja hoor, eerst vragen en dan later zelf het antwoord zo precies geven alsof het lijkt dat je heel slim bent. Mooi is dat! ;)

Ik ging ervan uit, dat je met een logisch antwoord zou komen op m'n vraag, maar dat viel een beetje tegen... :p

Maar eh, kloppen doet het wel he van die vertraging?

Er is sprake van een serieuze MIDI vertraging tussen verschillende MIDI kanalen, vanwege het vrij trage, seriële MIDI protocol.

Om te kijken of kanaal 1 minder last heeft van vertraging dan bijvoorbeeld kanaal 10, heb ik gisteren een kort onderzoekje gedaan. Op m'n Atari heb ik Cubase 3.02 op alle MIDI kanalen op hetzelfde tijdstip een noot laten starten en weer laten eindigen. Deze MIDI berichten heb ik verstuurd naar de MIDI-kaart in m'n PC en ik heb deze berichten daarop zichtbaar gemaakt met het programma MIDI-OX. En de resultaten:

- Bij het starten van de noten wordt eerst het Note On bericht voor kanaal 1 verstuurd. Daarna volgen kanaal 2,3,4, enz. In dit geval heeft dus kanaal 1 de minste vertraging en kanaal 16 de meeste.
- Bij het stoppen van de noten wordt eerst een Note Off bericht (een Note On met velocity 0 :) voor kanaal 16 verstuurd... Daarna volgen kanaal 15,14,13, enz. Kanaal 16 heeft nu dus de minste vertraging.

Het is vrij vaag dat er niet eerst een Note Off bericht naar kanaal 1 wordt verstuurd, want hierdoor zouden alle nootlengtes even lang zijn, wat nu niet het geval is. Door deze wat vreemde kanaalselectie bij een Note Off bericht duurt een noot op kanaal 1 bijna 30 milliseconde langer dan eenzelfde noot op kanaal 16... Misschien dat er bijgehouden wordt door de sequencer in welke richting hij de kanalen scant om zo de latency onder de kanalen beter te verdelen, ik weet het niet. Het is in ieder geval met de gebruikte opstelling niet waar, dat MIDI kanaal 1 altijd de minste latency heeft.

Trouwens is het ook nog eens zo dat bij midi keyboards ze een constant keep alive signaal uitsturen zodat de ontvangende kant (sequecer) snel genoeg kan reageren mocht er ooit een keer een note on bericht aankomen.

Dat keep alive signaal is het zogenaamde Active Sense bericht en dat is een verhaal apart. Het heeft de betekenis van: 'hé, ik ben er nog, maak je niet ongerust' en is bedoeld om haperingen van MIDI berichten tussen een zender (bijvoorbeeld een master keyboard) en ontvanger (bijvoorbeeld een synth module) op te lossen. De zender verzend een Active Sense bericht als er binnen een bepaalde tijd geen andere MIDI berichten verstuurd worden. Dit doet de zender elke 300 ms. De ontvanger weet dat als hij zo'n bericht binnenkrijgt, er dan niks vreemds aan de hand is, ook al heeft de ontvanger bijvoorbeeld nog een aantal MIDI noten aan staan. Als de ontvanger geen Active Sense berichten meer ontvangt, omdat bijvoorbeeld de MIDI-kabel tussen zender en ontvanger is losgeschoten, dan zal de ontvanger alle nog klinkende noten uitzetten. Active Sense kan heel handig zijn in live-situaties, waar per ongeluk een MIDI snoer naar een synth module of het netsnoer van je MIDI patchbay losgetrokken wordt. Je zult dan geen last hebben van noten, die blijven hangen tot in den eeuwigheid. ;) Maar...hierbij moeten zowel zender als ontvanger Active Sense ondersteunen en dat wordt alleen maar gedaan door sommige apparaten van Yamaha en Roland.

En mocht je via midi time code apparaten aan elkaar willen knopen is het aan te raden om ook weer een aparte midi lijn te gebruiken omdat tussen al dat time code geweld de timing van note on/off ook nog wel eens tegen kan vallen. Soms kan dit niet maar apparaten dat als MTC slave kunnen optreden hebben meestal ook een eigen sequencer en die zou je dan kunnen gebruiken om je note on/off commando's te sequencen.
(Waarom ik nog niet midi-b van m'n EX5 heb aangesloten snap ik zelf ook nog niet, zal wel iets met midi kabels te maken hebben)


Yep, MIDI Clock en MIDI Time Code gaan samen met onder andere 16 kanalen met allerlei MIDI berichten door 1 MIDI kabeltje en dan kan het af en toe wel eens druk worden.

Trouwens even heel iets anders. We lopen hier wel over ms en wat al niet meer te vozen, maar ik houd mezelf niet voor dat ik zo strak kan spelen binnen de paar ms hoor. Denk dat je eerder in de buurt van 10'en van ms komt als je helemaal nuchter bent.

De (kraanige) mensch is niet zozeer het probleem, nee. Het zijn de sequencers, die allerlei multitimbrale modules en samplers en andere grappen tegelijk moet aan sturen met behulp van het toch wat achterhaalde MIDI protocol.

Toch hou ik wel van MIDI. *D
 
Orgineel geplaatst door Boemtsjak
Om te kijken of kanaal 1 minder last heeft van vertraging dan bijvoorbeeld kanaal 10, heb ik gisteren een kort onderzoekje gedaan. Op m'n Atari heb ik Cubase 3.02 op alle MIDI kanalen op hetzelfde tijdstip een noot laten starten en weer laten eindigen. Deze MIDI berichten heb ik verstuurd naar de MIDI-kaart in m'n PC en ik heb deze berichten daarop zichtbaar gemaakt met het programma MIDI-OX. En de resultaten:

- Bij het starten van de noten wordt eerst het Note On bericht voor kanaal 1 verstuurd. Daarna volgen kanaal 2,3,4, enz. In dit geval heeft dus kanaal 1 de minste vertraging en kanaal 16 de meeste.
- Bij het stoppen van de noten wordt eerst een Note Off bericht (een Note On met velocity 0 :) voor kanaal 16 verstuurd... Daarna volgen kanaal 15,14,13, enz. Kanaal 16 heeft nu dus de minste vertraging.
Is dat typisch voor het midi protocol of misschien alleen voor Cubase op de Atari?
Zijn de note offs niet te zien als event in je event view, zodat je ze daarin kunt verschuiven?
 
Is dat typisch voor het midi protocol of misschien alleen voor Cubase op de Atari?

Alleen voor Cubase op de Atari. Maar waarschijnlijk werken de meeste sequencers wel zo

En je kan hier in de event view niets aan veranderen omdat daar alle note on's en off's op hetzelfde moment staan. Pas bij het uitsturen komt de prioriteit van kanalen aan de orde omdat je maar een signaal per keer kan versturen. Je kan wel beinvloeden welke berichten eerst worden verstuurd door zelf met de timing te gaan pielen.
 
Orgineel geplaatst door Synic
Is dat typisch voor het midi protocol of misschien alleen voor Cubase op de Atari?
Zijn de note offs niet te zien als event in je event view, zodat je ze daarin kunt verschuiven?

Het is inderdaad typisch voor Cubase 3.02 op de Atari. Ik weet niet of je in de event view de volgorde van gelijktijdige events nog kan veranderen. Ik zal vanavond daar even naar kijken en dan kijk ik gelijk wat Cubase en Logic op de PC met dit soort situaties doen. :)
 
Aangezien het de Nationale Oude-thread-omhoog-schop-dag is...


...wil ik dit verschijnsel nog eens even opnieuw onder de aandacht brengen. Erg belangrijk voor de punchiness en groove van je track, als je hier rekening mee houdt!
 
Back
Top