MIDI-engine voor sequencer in jvm, .net of toch c++

[n303y]

Het valt mij op dat er diverse threads zijn geweest waarin mensen zeer enthousiast waren om zelf een sequencer te schrijven waar we vervolgens niets meer van horen. Voorbeelden hiervan zijn link, link, link. Nu weet ik inmiddels uit eigen ervaring dat het toch wel tegenvalt een stabiele midi-engine te schrijven al weet ik niet of dit de reden was dat men afhaakte. Met een stabiele engine doel ik op de timing van een sequence die realtime moet kunnen worden gewijzigd. Dit is alsof je de inhoud van een collectie wijzigt terwijl een ander proces deze aan het itereren is. Ik ervaar dit probleem nu met met de C# MidiToolkit van CodeProject welke overigens de enige lijkt te zijn voor .net. Ik vraag mij daarom ook af of er uberhaupt ooit weleens iemand geweest is die dit wel is gelukt in .net of jvm en of dat ik er maar beter mee kan stoppen en mijn tijd investeren in C++. Daar is veel meer voor beschikbaar maar ben niet bekend met C++. Wie heeft ervaring met programmeren van een midi-sequencer? Als ik weet dat dit met .net moet kunnen stap ik namelijk niet over naar c++.

Overigens gaat dit over de sequencer van mijn 777 project welke een hapering geeft zodra de sequence gewijzigd wordt.

 

[Almeros]

Ik ga er zelf nog eens naar kijken voor mij Java audio projectje (Zie link beneden). Kan er nu nog niet veel zinnigs over zeggen. Java Sound bevat zelf ook een (niet realtime) MIDI player sequencer. Deze wil ik niet gaan gebruiken omdat ik het alle controle zelf in de hand wil houden.

Als het in C++ kan, wat zou dan de reden zijn dat het niet kan in .Net/Java etc. Wat vooral belangrijk is, is dat je gebruik gaat maken van een zo precies mogelijke timing. Voor Java heb je bijv. System.currenTimeMillis() om op de milliseconden precies te zien waar je zit. Maar deze is waarschijnlijk niet nauwkeurig genoeg. Java biedt wel oplossingen voor timings op nanoseconds, maar de timers kunnen nog weer meer/minder nauwkeurig zijn op verschillende platforms (Win98 tot Vista, of Linux of OS-X).

Verder ligt het aan de stabiliteit van de MIDI implementatie in Java.

Als ik meer weet laat ik het wel weten. Kan even duren want ik doe het in vrije tijd

 

[bikkel]

Je kunt wel retestrakke timing hebben in Java, maar wat als de interface tussen Windows en Java dat niet is? Ik maak me over Java an sich helemaal geen zorgen eigenlijk. De meeste mensen die over Java lopen te klagen weten vaak niet dat er toch in veel applicaties Java gebruikt wordt waar ze het niet aan merken.

 

[Yoozer]

Het punt is dat C# draait op een dik framework dat je een hele hoop leuke functies geeft maar dat dit het niet sneller maakt. Vroeger bakte je bedrijfssoftware in C, C++ of Pascal - tegenwoordig gebruik je daar C# voor omdat dat de ontwikkeltijd een hoop terugbrengt. Voor sequencers gelden echter andere eisen.

Harde realtime kom je sowieso niet tegen op PCs -daarvoor heb je embedded devices die een loop uitvoeren waarvan elke stap bekend moet zijn qua tijdskosten.

Wat je noemt van collecties en itereren - ik denk dat je een andere aanpak moet proberen. Kijk eens of je een analoog kunt vinden in de welbekende graphics buffer; op het moment dat er een wijziging plaatsvindt wordt 'ie in de buffer gezet, en de software leest nadat 'ie de huidige pagina heeft gelezen (met de oorspronkelijke data) de buffer uit.

Nu heb ik geen zak verstand van C++, maar da's hoe ik het zou aanpakken .

 

[etaoin]

Vroeger bakte je bedrijfssoftware in C, C++ of Pascal

Ik denk dat juist de bedrijfssoftware, die veel minder vluchtig is dan de consumentensoftware, het minst in nieuwe talen wordt geprogrammeerd.

Intel heeft net een gloedjenieuwe Fortran-compiler uitgebracht voor het i7-platform. Je moest eens weten hoeveel ouwe meuk er nog in bedrijven wordt gebruikt . . .
(er wordt ook nog zat COBOL gebruikt bij de banken en verzekeraars)

 

[Meinte37]

Anders gezegd: 80% van je hele leven wordt geregeld door COBOL-meuk

 

[Yoozer]

Ik denk dat juist de bedrijfssoftware, die veel minder vluchtig is dan de consumentensoftware, het minst in nieuwe talen wordt geprogrammeerd.

Komt ook nog eens erbij dat je van die creatieve hobbyisten hebt die in Access iets in elkaar draaien waar de honden geen brood van lusten, en voordat je het weet is het een bedrijfs-kritische applicatie geworden die al 8 jaar meegaat.

(er wordt ook nog zat COBOL gebruikt bij de banken en verzekeraars)

Klopt, omdat het niet leuk is om al die idiote financiële regels opnieuw te gaan debuggen, want fouten kosten echt geld.

 

[n303y]

Almeros, ik had die thread van je eerder gelezen. Ziet er opzich erg handig uit en ben ook benieuwd hoe het loopt als je met de sequencer bezig bent.

Yoozer, ik vermoed dat de snelheid van het framework (1.1 overigens!) in mijn geval niet het probleem is maar eerder het ontwerp. De aanpak van die collectie zit in de MIDI Toolkit die ik gebruik en is inderdaad voor realtime niet de juiste aanpak. Voordat ik de midi-engine daarvan herschrijf wil ik zeker weten of het uberhaupt wel te doen is, vandaar deze post. Het valt mij ook op dat er geen voorbeelden zijn van een realtime midi-sequencer in .net vandaar de twijfels want dit is toch niet voor niets zou je denken. De eisen die ik stel op het gebied van timing zijn denk ik ook niet zo extreem: 6 ticks per kwartnoot met maximaal 250 bpm.
Over het "harde realtime": ik heb seq303 nog eens gedownload maar die timing in realtime vind ik toch wel perfect en is qua functionaliteiten heel erg vergelijkbaar met mijn programma.

 

[zmooc]

Ik heb niet zoveel ervaring met C# en met Windows en heb ook (nog) geen MIDI sequencer geschreven, maar ik heb wel mijn eigen software synthesizer in C++ geschreven (onder Linux) en daarbij loop je op zich tegen soortgelijke problemen aan: als je teveel datastructuren on-the-fly probeert te veranderen terwijl je ze aan het afspelen bent dan hapert het. Dat is een kwestie van je datastructuren slim in elkaar steken en zorgen voor fine-grained locking. Dat speelt in alle programmeertalen/-omgevingen en ligt heus niet aan C# en de .NET CLR. Op Internet kom je ook meer dan genoeg verhalen tegen over .NET applicaties die een nog veel lagere latency vereisen dan een MIDI sequencer en dat gaat blijkbaar prima.

Dus als het "gewoon" goed werkt en alleen mis gaat als je veel data probeert aan te passen, zou ik concluderen dat het prima kan maar dat je het gewoon nog slimmer in elkaar moet steken qua locking, threading en de manier waarop je je datastructuren opbouwt, uitleest en aanpast. Wat je vooral ook niet moet doen, zijn dingen als logging of andere system calls vanuit dezelfde thread als waarin je met je datastructuur bezig bent. En vooral veel threads gebruiken voor ieder afzonderlijk wissewasje dat parallel kan.

Maar ik raad je sowieso af om naar C++ over te stappen; ik kende C++ op zich prima maar werkte al jaren uitsluitend met Java en als je dan weer overstapt naar C++ is het een ontzettend bewerkelijke frustrerende chaotische troep-taal De reden dat ik toch weer voor C++ gekozen heb, is dat ik platform-onafhankelijkheid wil en vendor lock-in wil vermijden (de andere optie was Java omdat ik daar dagelijks mee werk). Maar zo te horen zijn dat geen issues die bij jou spelen, dus gewoon lekker C# gebruiken, scheelt je een boel kopzorgen, en die heb je al genoeg als je iets realtimerigs in elkaar aan het flansen bent

(Overigens werkt C# prima onder andere OSen met de Mono Runtime en kun je C++ ook prima draaien onder de .NET CLR.)