Emagic Unitor-8 / Midi Interface latency tweaking

[Hanz]

Origineel geplaatst door fuse
Het is wel degelijk een goede test omdat hij een relatief goede voorstelling van de praktijk situatie is en door toepassing van MTC én midi clock je een hoge load op je midi outputs zet. Dat dit dan intelligent wordt afgehandeld maakt dan niet zoveel uit. Desnoods ga je aan wat knoppen draaien zodat je cc's erbij krijgt. Het gaat om het aantal data wat je over die lijn gooit en of die stabiel is en blijft qua serieel signaal.

Als het je erom gaat om zoveel mogelijk lijnbelasting te creeren, dan is dat misschien een loflijk streven, dat ben ik dan op zich wel met je eens. Aan de andere kant moet het ook wel een representatieve test zijn; we zoeken niet de interface die het meest efficient data weg kan bulken, maar de interface die 'representatief midi gebruik' het strakst doorgeeft tussen devices en DAW.

Om redenen uit m'n vorige post vind ik midi clock geen geschikte kandidaat voor het 'opvullen' van de MIDI stream, maar MidiTest genereert de 'vulling' waar je het over hebt middels de complete set MIDI commando's, incl. MTC en CC's.
Dat is dus minstens even goed.

Als je jitter en al die andere parameters wilt testen dan lijkt mij dat je met een scoop veel betere resultaten kan behalen omdat die tenminste te calibreren is. En als je een redelijk uitgebreide hebt kan die ook wat meer type metingen uitvoeren. Maar goed, niet iedereen heeft zo'n apparaat thuis staan.

Een alternatief is het speciale MIDI-snoertje wat men bij Sound-on-Sound gebruikte.

Ik denk dat je daarmee al een eind komt qua meting. Wat je nog niet hebt is verwerking van de gegevens.
Waarom ik zo vasthoud aan Miditest is omdat deze een grote hoeveelheid gegevens (ivm. statistische verantwoording) makkelijk kan vertalen naar een klein aantal rapportage-gegevens.

Zover ik weet is er niet een redelijk simpele manier om van scoop-metingen te komen naar een rapportage, zonder enorme hoeveelheden handwerk of professionele apparatuur / software.

Je geeft al aan dat je zelf apparaten hebt die anders op een midi clock reageren. IMHO zou dan een goede midi interface tenminste er voor moeten zorgen dat al deze goed te syncen zijn via die midi. Dat lijkt iig een zeer goede test om te kijken of hij doet wat hij moet doen, vooral met duurtesten bijvoorbeeld. In de praktijk zie je dan ook vaak dat syncing met midi een van de moeilijkste dingen is om goed te krijgen. En dat is juist een goede indicatie of het wel strak is of niet.

Nee, niet helemaal. Het gaat om de meest strakke doorgifte van MIDI bytes, waaronder de Midi clock commando's.
Wat een apparaat in de MIDI keten er vervolgens van brouwt, dat interesseert me in die mate niet, dat dit ontzettend apparaat-afhankelijk is. En we willen niet de apparaten meten, maar de interface.

Miditest is wel een leuke test programma maar je test altijd maar op 1 poort en dan krijg je andere resultaten als je met die 8 poorten test. En je gebruikt hem (neem ik aan) altijd met die 8 poorten.

In hoeverre de resultaten anders zijn met het gebruik van meerdere poorten tegelijk, dat weet ik dus niet zo.
Wellicht eens de moeite van het proberen waard of dit echt zo is. Als we dit kunnen elimineren, dan zou dit de tests natuurlijk enorm vereenvoudigen. Waarom gebruik van meerdere poorten t.o.v. een volledig belaste enkele poort veel zou kunnen uitmaken is me nog niet echt duidelijk.

Qua programma zelf lijkt het me meer bruikbaar om midi-thru loops te testen. Dat wordt op de pagina ook beweert. Maar zelf ben ik een groot tegenstander hiervan omdat je dan qua latency helemaal nat kan gaan. [/B]

Wil je dit eens uitleggen? Ik heb dit nergens op de pagina van Miditest gevonden, het woord 'thru' wordt er niet gebruikt.
Zie http://earthvegaconnection.com/evc/products/miditest/
Miditest maakt gebruik van directe out/in loopbacks. Dus een MIDI interface output direct aan een MIDI interface input koppelen met een gewone MIDI kabel. Programma verstuurt MIDI bytes richting de output en meet deze bij de input. Zover ik kan zien is er niet een betere manier om puur de performance van de MIDI interface te meten; immers de kabel zal een verwaarloosbare invloed hebben.

 

[fuse]

Dat je met miditest de thru performance kon meten stond in een SOS artikel meen ik te weten. Iig was dat de suggestie van de auteur. Maar goed.

Midi clock is het meest tijdkritische midi commando dus lijkt me het niet meer als logisch om dit als meetstaf te gebruiken. Bij seriele communicatie zie je wel vaker een constante stroom van data als het gaat om testen van stabiliteit. Dat is nl. ook makkelijker met een scoop te meten.
Je hebt ook van die scoop kaarten voor in je computer en dan wordt dit soort testen een makkie lijkt me.

Zowieso snap ik die obsessie voor lijstjes ook niet zo goed. Je wel de prestatie van zo'n ding meten en dan zijn die hele mooie lijstjes van miditest wel leuk maar dan nog ben je maar in een paar parameters geinteresseerd IMHO. En die zou je dan als het goed is moeten kunnen matchen met de specificaties van het midi protocol.
Maar als om een of andere onvoorziene reden je apparaat niet helemaal aan dat protocol voldoet zul je nog steeds alleen in de praktijk hierachter komen.

En qua poorten was er volgens steinberg destijds een balangrijk verschil in het aantal omdat dan de latency per poort lineair zou oplopen. En met LTB zou dit niet zo zijn.
Die grafiekjes heb ik niet kunnen vinden nog maar het iig een goede aanduiding dat er toch verschil in zou kunnen zijn tussen 1 en meerdere poorten. Volgens steiny tenminste.

 

[Hanz]

Origineel geplaatst door fuse
Dat je met miditest de thru performance kon meten stond in een SOS artikel meen ik te weten. Iig was dat de suggestie van de auteur. Maar goed.

Nergens kunnen vinden. Het zal best kunnen, maar meten van thru performance (van hardware apparaten?) is totaal niet interessant in dit geval, dus dat gaan we ook niet helemaal niet doen.
We testen gewoon met de aanbevolen manier van aansluiten, middels loopback dus.

Aangezien je misconceptie over de toegepaste werkwijze je grootste probleem met MidiTest vormde, neem ik aan dat je bezwaren tegen het gebruik van dit programma zijn weggenomen?

Midi clock is het meest tijdkritische midi commando dus lijkt me het niet meer als logisch om dit als meetstaf te gebruiken.

Waarom is MIDI clock het meest tijdskritisch, kritischer dan bijv. een Note On?
Juist bij Note On kan je bij slechte timing bijv. flam-effecten verwachten, hoe een apparaat omgaat met fluctuerende MIDI clock is weer totaal apparaat-afhankelijk en hoeft niet eens merkbaar te zijn.

Trouwens, binnen MIDI bestaat er niet zoiets als 'class-of-service' dus zijn alle MIDI commands even tijdskritisch.
Dat wil zeggen: het meten op basis van een Note On commando of MIDI CC levert exact dezelfde timing-informatie.
Waarom het niet zinvol is om specifiek Midi Clock te gebruiken heb ik al aangegeven (afwijkende afhandeling door bijv. de Unitor8, geeft verstoring van de test.)

Bij seriele communicatie zie je wel vaker een constante stroom van data als het gaat om testen van stabiliteit. Dat is nl. ook makkelijker met een scoop te meten.
Je hebt ook van die scoop kaarten voor in je computer en dan wordt dit soort testen een makkie lijkt me.

Je hebt het hier vermoedelijk over het meten van jitter. Dat is precies wat er gebeurt in Miditest, alleen dan op een hoger logisch niveau. Het gebruik van een scoop lijkt me hier bijzonder weinig toevoegen.

Zowieso snap ik die obsessie voor lijstjes ook niet zo goed. Je wel de prestatie van zo'n ding meten en dan zijn die hele mooie lijstjes van miditest wel leuk maar dan nog ben je maar in een paar parameters geinteresseerd IMHO. En die zou je dan als het goed is moeten kunnen matchen met de specificaties van het midi protocol.
Maar als om een of andere onvoorziene reden je apparaat niet helemaal aan dat protocol voldoet zul je nog steeds alleen in de praktijk hierachter komen.

De 'obsessie voor lijstjes' beperkt zich tot een aantal kritische kengetallen. Nogmaals: latency, jitter en peak jitter.
Dat lijkt me toch niet te veel gevraagd.
Wat je wellicht onderschat is het verkrijgen en verwerken van een voldoende grote, statistisch significante steekproef.
Dat maakt grotendeels het verschil waarom bijv. testen met 20.000 MIDI events wèl statistisch verantwoord is, en even naar de display van de K-station koekeloeren niet.

Het verhaal van vergelijken met de 'specificaties' van het midi protocol is niet relevant.
Er bestaan weinig eisen in het midi protocol wat betreft latency en jitter, daar was men toenertijd amper mee bezig in muziek-kringen.

Voordat we nou in een cirkeltje gaan praten, een samenvatting:
1) Ik doe een meting met het programma Miditest. Dit, omdat ik dit denk te kunnen gebruiken om een verantwoorde uitspraak te doen over evt. prestatie-verhogende tweaks voor bezitters van een Emagic interface.
2) Fuse stelt vervolgens (na een hele discussie) dat mijn meetmethode niet correct is (en dus onbetrouwbaar) - komt vervolgens met een te gebruiken meetmethode die ik vervolgens onderbouwd weerleg.
3) Fuse stelt nu vervolgens te stellen dat meten niet zinvol is, maar dat het alleen mogelijk is 'in de praktijk hierachter te komen' wat de timing-betrouwbaarheid (?) van de interface is.

Sorry, Fuse, maar dat verhaal strookt niet helemaal. Wat wil je nu zeggen?

En qua poorten was er volgens steinberg destijds een balangrijk verschil in het aantal omdat dan de latency per poort lineair zou oplopen. En met LTB zou dit niet zo zijn.
Die grafiekjes heb ik niet kunnen vinden nog maar het iig een goede aanduiding dat er toch verschil in zou kunnen zijn tussen 1 en meerdere poorten. Volgens steiny tenminste. [/B]

Ik ben erg benieuwd naar je bronnen...

 

[fuse]

Origineel geplaatst door Hanz
Nergens kunnen vinden. Het zal best kunnen, maar meten van thru performance (van hardware apparaten?) is helemaal niet interessant in dit geval, dus dat gaan we ook niet helemaal niet doen.

Dit lijkt me juist een goede toepassing om te kijken welke thru ketens je het beste zou kunnen gebruiken. Maar goed praktijk voorbeelden spreken waarschijnlijk niet echt tot je verbeelding blijkt.

We testen gewoon met de aanbevolen manier van aansluiten, middels loopback dus.

Lijkt me logisch dat je aanbevelingen van het programma opvolgt. Maar dat hoeft niet automatisch te betekenen dat je niet na hoeft te denken over een goede representatieve testopstelling.
Neem nou bijvoorbeeld de beslissing om de USB of seriele aansluiting te gebruiken.

Aangezien je misconceptie over de toegepaste werkwijze je grootste probleem met MidiTest vormde, neem ik aan dat je bezwaren tegen het gebruik van dit programma zijn weggenomen?

Absoluut niet. Je vergeet nog steeds het feit dat je met dit programma maar een poort tegelijkertijd kan testen. Het zal dus hoogstens een onderdeel van de prestatie van je interface tonen. Wil je de gehele prestatie tonen zul je ook alle poorten tegelijkertijd moeten testen. En als je invloed van gebruik van meerdere poorten zou je zelfs de testopstelling kunnen uitbreiden door 1,2,3...8 poorten tegelijkertijd testen. Wellicht zit daar een lineaire factor in. Wat Steinberg bijvoorbeeld beweert.
Wellicht dat jij de relevantie hiervan niet inziet hoeft mijn inziens niet te betekenen dat die wel degelijk van invloed kan zijn. Al helemaal omdat je zoveel waarde hecht aan objectieve metingen. Dan is dit wel het minste wat je kan doen dunk mij.

Waarom is MIDI clock het meest tijdskritisch, kritischer dan bijv. een Note On?
Juist bij Note On kan je bij slechte timing bijv. flam-effecten verwachten...

Midi is een serieel protocol dus via een kabel zul je nooit 2 noten exact op dezelfde tijd kunnen aansturen. Sterker nog, dit wordt regelmatig bij commerciele midi files gebruikt om op een goedkope manier chorus effecten te bereiken.
En Trash merkte ook al op dat hij het een automatische groove vondt.
Wat mij betreft hoef je dan niet te quantizen en gewoon met een goede groove in te spelen.
En komt nog eens bij dat je met een constant signaal het beste instabiliteiten kan meten. Je kan als referentie ook een mix van berichten testen om te kijken of dit invloed heeft.
En misschien zelfs zo'n midi file met extreem veel noten en kijken of je met een aantal interfaces verschil zou merken qua timing.

Trouwens, binnen MIDI bestaat er niet zoiets als 'class-of-service' dus zijn alle MIDI commands even tijdskritisch.
Dat wil zeggen: het meten op basis van een Note On commando of MIDI CC levert exact dezelfde timing-informatie.
Waarom het niet zinvol is om specifiek Midi Clock te gebruiken heb ik al aangegeven (afwijkende afhandeling door bijv. de Unitor8, geeft verstoring van de test.)

Juist wel. Omdat het midi clock signaal wordt gebruikt om de tempo te bepalen.
In het geval van de K-station is dit extra interessant omdat deze synth qua CPU/DSP power nou niet echt uitblinkt (een redelijk bekend fenomeen wat menig bezitter kan onderschrijven). Dus krijgt hij maar de beperkte mogelijkheid om het tempo te bepalen en is in die zin extreem gevoelig. Dat is iets waar je toevallig tegenaan loopt maar op dat moment kwam het mij iig heel goed uit.

Je hebt het hier vermoedelijk over het meten van jitter. Dat is precies wat er gebeurt in Miditest, alleen dan op een hoger logisch niveau. Het gebruik van een scoop lijkt me hier bijzonder weinig toevoegen.

Een scoop is speciaal bedoeld om te meten. Lijkt mij raar om dan iets anders te beweren.

De 'obsessie voor lijstjes' beperkt zich tot een aantal kritische kengetallen. Nogmaals: latency, jitter en peak jitter.
Dat lijkt me toch niet te veel gevraagd.
Wat je wellicht onderschat is het verkrijgen en verwerken van een voldoende grote, statistisch significante steekproef.
Dat maakt grotendeels het verschil waarom bijv. testen met 20.000 MIDI events wèl statistisch verantwoord is, en even naar de display van de K-station koekeloeren niet.

Nogmaals een goede objectieve meting zou als hij goed opgezet en uitgevoerd wordt dezelfde resultaten moeten geven als een praktische test. Je had het zelf al over hoe uitvoerig je zoiets zou kunnen meten. Dan zou je ook kunnen twisten over welke opstelling sneller uit te voeren is.

Het verhaal van vergelijken met de 'specificaties' van het midi protocol is niet relevant.
Er bestaan weinig eisen in het midi protocol wat betreft latency en jitter, daar was men toenertijd amper mee bezig in muziek-kringen.

Natuurlijk is het wel relevant. Je hebt er immers toch last van? Ik bedoel. Waarom zou je uberhaupt je midi interface gaan tweaken als hij naar behoren werkt?

Voordat we nou in een cirkeltje gaan praten, een samenvatting:
1) Ik doe een meting met het programma Miditest. Dit, omdat ik dit denk te kunnen gebruiken om een verantwoorde uitspraak te doen over evt. prestatie-verhogende tweaks voor bezitters van een Emagic interface.
2) Fuse stelt vervolgens (na een hele discussie) dat mijn meetmethode niet correct is (en dus onbetrouwbaar) - komt vervolgens met een te gebruiken meetmethode die ik vervolgens onderbouwd weerleg.
3) Fuse stelt nu vervolgens te stellen dat meten niet zinvol is, maar dat het alleen mogelijk is 'in de praktijk hierachter te komen' wat de timing-betrouwbaarheid (?) van de interface is.

Sorry, Fuse, maar dat verhaal strookt niet helemaal. Wat wil je nu zeggen?

1) Je test is maar een gedeeltelijke test omdat je testen beperkt bij 1 poort
Om je resultaat van tweaken te testen is het wel een goede indicatie.

2) Je weerlegt mijn methode niet echt en het enige wat je doet is er je mening over geven. Je zou het tenminste als een referentie test kunnen gebruiken. Iets gezien de duur van de test lijkt me dat geen hele grote uitdaging.

3) Je gebruikt je interface juist in de praktijk dus lijkt mij het niet meer dan normaal dat een praktijktest het dichtst bij de situatie komt waarin je je interface gaat gebruiken.

Ik ben erg benieuwd naar je bronnen...

Dat artikel van Steinberg kan ik helaas niet vinden. Dus zul je wat dat betreft maar moeten geloven dat mijn geheugen op dat vlak iig redelijk in orde is want na 3 jaar kan ik iig nog posts redelijk onthouden qua inhoud.

En ik snap wel dat je erg gebrand bent om jou ideeen hierover vast te houden. Ik iig niet anders verwachten. Maar het lijkt me helemaal niet verkeerd om mijn voorstel qua testen als referentie te gebruiken. Iets wat in de wetenschappelijke wereld redelijk normaal is. Want dan heb je iig een breder kader waarin je je resultaten kan plaatsen. En dat is iets waar de rest die hier vol spanning mee zit te kijken wel benieuwd naar lijkt me.

 

[ProtoHuman]

Bericht door een moderator:

Een aantal offtopic posts verwijderd

 

[Ensemble]

Ok ontopic dan maar.

Zou het voor de strakheid van je beats uitmaken of je je drums in je arranger (in whatever sequencer) op de eerste rij of bijvoorbeeld na enkele andere instrumenten op bijv. de 8 ste rij stopt?

Dus is rij 1 vanwege het seriele karakter van midi beter dan rij 8 of denk ik krom?

Dank en groet,

ens

 

[ProtoHuman]

Fuse, nog even over jou meetmethode. Je gebruikt de K-station om de midi clock af te lezen. Waar heb je naar gekeken? Schommelingen in de clock, of verschillen t.o.v. van de waarde ingesteld in cubase? De k-station kan alleen in hele beats aflezen toch? (dus bijvoorbeeld geen 134,2 bpm). Eerlijk gezegd lijkt me dat niet erg precies om af te lezen. Maar hoe groot waren de verschillen?
Je geeft zelf al aan dat de K-station vrij weinig CPU heeft, en daardoor qua midi clock niet altijd even stabiel is. Uit ervaring weet ik dat de K-station inderdaad niet altijd erg strak is, en nogal eens uit sync wil gaan lopen (o.a. geprobeerd met cubase, RM1x). Ik merkte dat de K-station er nog wel eens naast zat, terwijl andere apparaten wel strak bleven lopen. Nu vind ik het een beetje raar dat je een apparaat gebruikt, die ZELF niet strak is qua clock, om te testen of een ANDER apparaat strakke midi-clock doorgeeft. Heb je het ook nog bij andere apparatuur geprobeerd? Er zijn nog wel een aantal apparaten die midiclock kunnen aflezen, dus dat zou in deze discussie misschien wel interessant zijn.

 

[fuse]

ProtoHuman, je bent het met me eens dat de K-station heel gevoelig is op het vlak qua timing.
En als je hem synct gebruik je dan een 'gewone' midi interface of eentje die speciaal geschikt is voor de sequencer?
En in mijn geval kreeg ik hem alleen goed gesynced met een AMT in Logic 5.5 en een midex in Cubase. (Atari had ik toen niet meer maar die heeft iig de reputatie om retestrak te zijn.)
En dat spreekt dan jouw bewering tegen dat de K-station in zichzelf instabiel is tegen wat mij betreft. Hij is behoorlijk gevoelig heb ik het idee. En dat maakt hem dan een ideaal apparaat om een lakmoes proef mee uit te voeren.
Toentertijd was er nog geen miditest beschikbaar dus moest het wel op een andere manier getest worden. Blijkbaar dus iets wat mijn inziens zijn praktisch nut wel heeft bewezen.

En trouwens heb ik nog steeds een aantal vragen waar Hanz volgens mij nog geen antwoord op heeft gegeven.

Wat was eigenlijk de aanleiding om dit hele midi avontuur aan te gaan? Had je zelf hier problemen mee of was het iets anders? Miste je bijvoorbeeld een bepaalde strakheid bij je midi setup?

Als hier toch naar het onderzoeken bent geslagen waar heb je eigenlijk niet op dit forum gezocht? Of tenminste laten weten dat je wel had gezocht maar toch nog meer wilde weten?

Denk je nu ik zelf de posts uit het verleden voor je heb opgezocht dat dit op zich al een redelijke onderbouwing is van wat ik eerder beweerd heb. Of wil je persé toch orginele bronvermeldingen?

Ben je het met me eens dat voor Cubase een midex de meest optimale interface is om te gebruiken?

Wat is volgens jouw de bepalende factor van de meetuitkomsten van miditest. Is dit message jitter, de message average time of de message maximum time?

Ga je naast de unitor nog een andere midi interface testen om te kijken in hoeverre die USB tweaks invloed hebben op de midi prestaties? Of bijvoorbeeld een 'to host' usb aansluiting om te kijken of dat type 'midi' ook een andere prestatie heeft?

 

[mikemix]

De ene K-station is de ander niet, en daar ga je weer...
Dan zal je er meerdere moeten testen om van een benchmark te kunnen spreken....
Ik bedoel, die lat heb je nu zelf zo gelegd.

 

[fuse]

Zo ken ik er ook nog wel een.
Dat je de testen met meerdere unitors uit moet voeren om te kijken of daar nog verschil tussen zit.

Beetje wazig zo mike.

 

[ProtoHuman]

Verschillende K-stations proberen hoeft niet, maar andere apparatuur proberen zou wel mooi zijn. Als je kan laten zien dat ook andere apparaten meer moeite hebben met Cubase+Unitor, dan wordt je conclusie een stuk sterker.
Je hebt nu alleen laten zien dat de combinaties cubase/unitor/k-station en logic/midex/k-station niet lekker zijn. Natuurlijk, dit is een sterke aanwijzing dat een dedicated interface beter werkt. Maar je conclusie dat alle apparaten moeite hebben met cubase/unitor vind ik wat te voorbarig. Een test met andere gear zou me dus zeer interessant lijken! En ik ben ook benieuwd of Hanz zijn tweaks invloed zouden hebben op de K-station metingen.

 

[bronswerk]

Trouwens, binnen MIDI bestaat er niet zoiets als 'class-of-service' dus zijn alle MIDI commands even tijdskritisch.
Dat wil zeggen: het meten op basis van een Note On commando of MIDI CC levert exact dezelfde timing-informatie.
Waarom het niet zinvol is om specifiek Midi Clock te gebruiken heb ik al aangegeven (afwijkende afhandeling door bijv. de Unitor8, geeft verstoring van de test.)

Waarom is MIDI clock het meest tijdskritisch, kritischer dan bijv. een Note On?
Juist bij Note On kan je bij slechte timing bijv. flam-effecten verwachten...

Even ter info: midiclock, een zg "Realtime" message, heeft voorrang boven een Note-On message. Ik vind dat midiclock in de praktijk meer problemen geeft dan diverse Note-On messages vlak na elkaar. Het versturen is niet zo'n probleem, maar vooral de ontvangende zijde geeft vaak ellende, dat is mijn ervaring althans. Starten te laat, lopen niet in sync of zwabbert enz. Een test die inzicht geeft in midiclock vind ik eigenlijk nog belangrijker.

 

[Yoonchi]

Origineel geplaatst door fuse
Je vergeet nog steeds het feit dat je met dit programma maar een poort tegelijkertijd kan testen. Het zal dus hoogstens een onderdeel van de prestatie van je interface tonen. Wil je de gehele prestatie tonen zul je ook alle poorten tegelijkertijd moeten testen. En als je invloed van gebruik van meerdere poorten zou je zelfs de testopstelling kunnen uitbreiden door 1,2,3...8 poorten tegelijkertijd testen. Wellicht zit daar een lineaire factor in. Wat Steinberg bijvoorbeeld beweert.
Wellicht dat jij de relevantie hiervan niet inziet hoeft mijn inziens niet te betekenen dat die wel degelijk van invloed kan zijn. Al helemaal omdat je zoveel waarde hecht aan objectieve metingen. Dan is dit wel het minste wat je kan doen dunk mij.

Wat beteft het testen via slechts 1 poort bij het programma MidiTest ben ik helemaal mee eens dat het programma niet toereikend is. Had ook liever gehad dat je kon testen met meerdere poorten tegelijkertijd.
Maar misschien is de volgende test opstelling een idee:
Je kunt immers voor de MIDI input een andere poort pakken als voor de MIDI output, dus
1. Neem bijv. poort 1 voor MIDI input en poort 2 voor MIDI output en verbind met MIDI kabel Input 1 met Output 2 en,
2. Verdubbel de hoeveelheid data in MidiTest, eventueel gebruik je sequencer en/of een externe sequencer om data te genereren en meet wat het met MidiTest voor resultaat geeft.

Ik heb de test met deze 2 punten gedaan, exclusief de extra data van sequencers en het geeft geen significante verschillen met het testen via input en output op dezelfde poort; volgens de test een verschil van 20 micro seconde op 4.4 milli seconde, halve procent.

-Edit-
Wat ik wel later in de resultaten zag was dat de jitter wel hoger zit, en dus de spreiding van de latency van de events veel groter is, zeker 50% hoger. Dus het gebruik van meerdere poorten heeft wel degelijk invloed op, in mijn geval dan, een simpele MIDIsport interface.


Yoonchi

 

[Yawgmoth]

Bericht door een moderator:

Offtopic afgesplitst.

 

[Resonance]

Origineel geplaatst door Yawgmoth

Bericht door een moderator:

Offtopic afgesplitst.

waar naar toe?

 

[mikemix]

Prullenbak

 

[fuse]

Heeft iemand anders wellicht nog getest en interessante resultaten behaald?
Denk dat de OP wel klaar is met testen.

 

[Hanz]

Mijn tip van de dag: Denken voor anderen is nergens voor nodig, voor jezelf denken is meer dan genoeg.

 

[Catalunya]

Hanz!

Ga je nog een vergelijking doen tussen USB en Serieel? Ben wel benieuwd eigenlijk

groet Erik

 

[Rvooh]

waarom is dat nodig?

iedereen weet dat serieel beter zal zijn...