audiocollage
Ouwe rot
- Lid sinds
- 30 april 2009
- Berichten
- 3.158
Hmm, er is ook een nieuwere versie 3.0 met 460 pagina's !
sounddiver v3.0
Die oude komt nog van m'n SD-CD.
"Hardware" editors
- Thread starter obiwanjacobi
- Start date
sounddiver v3.0
Die oude komt nog van m'n SD-CD.
Heu ?? amai, maar update die link is audiocollage, want die werkt precies nog ni ??
'K Heb mij altijd wel verwondert en afgevraagt hoe die sounddiver aan zulke grote library is geraakt,,
EDIT:
okey,t is gelukt, met save as vanop hier: http://www.deepsonic.ch/deep/htm/manuals.php
'K Heb mij altijd wel verwondert en afgevraagt hoe die sounddiver aan zulke grote library is geraakt,,
EDIT:
okey,t is gelukt, met save as vanop hier: http://www.deepsonic.ch/deep/htm/manuals.php
Laatst gewijzigd:
obiwanjacobi
Ingeburgerd
- Lid sinds
- 22 oktober 2012
- Berichten
- 75
Dank voor de manuals. Ik zal ze - vooral de programming manual- aandachtig doorlezen.
Ik zie nog wat vragen en onduidelijkheden voorbij komen en zal deze proberen nog even toe te lichten.
Waarom kan jou computer een bestand laden en een plaatje laten zien - of een filmpje of een word document of wat ook?
Omdat de BETEKENIS van de bytes die in dat bestand bekend zijn en het desbetreffende programma code is ingebakken die dit inleest, vertaalt, transformeert, rangschikt / structureert en vervolgens weer transformeert naar je beeldscherm.
Hoe zou een programma met een Midi SysEx bericht kunnen werken? Het zou de BETEKENIS van de bytes in het bericht moeten weten. Veel programmas bakken die functionaliteit die daarvoor nodig is in het programma in. Voordeel: het is relatief eenvoudig. Nadeel: alleen dat ene bericht (of dat ene aparaat) wordt dan ondersteund.
Maar wat als je een programma nou leert lezen; net zo goed als jij boeken kan lezen over allerlei verschillende onderwerpen, Je hoeft niet voor elk boek op nieuw te leren lezen want de regels (letters, woorden, grammatica) zijn je duidelijk en zolang we die regels allemaal blijven gebruiken - kunnen we volgen wat er staat geschreven.
Dat is precies wat ik van plan ben te bouwen. Een programma dat de verschillende device sysex kan lezen. Daarvoor moeten we voor elk device de sysex 'syntax' beschrijven omdat het voor elk aparaat anders is (als ze zich aan 1 afspraak hadden gehouden net zoals bij ons lees-voorbeeld was het een stuk eenvoudiger). Ik ben een manier aan het ontwikkelen waarmee het programma kan achterhalen wat de BETEKENIS is van de inhoud van een SysEx bericht door de bytes uit het SysEx bericht te interpreteren aan de hand van deze beschrijving.
Nadeel is echter dat er voor elk device zo'n beschrijving gemaakt moet worden die het programma kan gebruiken. Voordeel is dan wel weer: omdat de 'taal' waarin deze beschrijvingen gemaakt worden WEL weer vastgelegd is (en het programma functionaliteit heeft ingebakken die daarmee om kan gaan) kan de 'rest' (bijv. schermen) behoorlijk automatisch gaan.
Ik snap dat sommige van jullie nog wat sceptisch blijven over de haalbaarheid van dit hele verhaal. Ik heb echter zelf alle vertrouwen in het principe en de ingeslagen richting. Er zullen nog zeker momenten komen waar ik 'problemen' tegen kom die ik niet had (kunnen) voorzien, maar de code is erg flexibel en uitbreidbaar opgezet.
Op dit moment ben ik bezig met het schrijven van een test applicatie voor mijn U-220. De SysEx beschrijving-afhandeling werkt nu goed (getest met de U-220) en ik ga nu kijken hoe het zich houdt in een 'echte' applicatie. Het wordt een 'hard-coded' applicatie - niks waarmee je schermen ofzo kan ontwerpen. Het is mijn bedoeling een applicatie te maken waarmee ik zo ook andere 'beschrijvingen' kan gaan testen.
Ik zie nog wat vragen en onduidelijkheden voorbij komen en zal deze proberen nog even toe te lichten.
Waarom kan jou computer een bestand laden en een plaatje laten zien - of een filmpje of een word document of wat ook?
Omdat de BETEKENIS van de bytes die in dat bestand bekend zijn en het desbetreffende programma code is ingebakken die dit inleest, vertaalt, transformeert, rangschikt / structureert en vervolgens weer transformeert naar je beeldscherm.
Hoe zou een programma met een Midi SysEx bericht kunnen werken? Het zou de BETEKENIS van de bytes in het bericht moeten weten. Veel programmas bakken die functionaliteit die daarvoor nodig is in het programma in. Voordeel: het is relatief eenvoudig. Nadeel: alleen dat ene bericht (of dat ene aparaat) wordt dan ondersteund.
Maar wat als je een programma nou leert lezen; net zo goed als jij boeken kan lezen over allerlei verschillende onderwerpen, Je hoeft niet voor elk boek op nieuw te leren lezen want de regels (letters, woorden, grammatica) zijn je duidelijk en zolang we die regels allemaal blijven gebruiken - kunnen we volgen wat er staat geschreven.
Dat is precies wat ik van plan ben te bouwen. Een programma dat de verschillende device sysex kan lezen. Daarvoor moeten we voor elk device de sysex 'syntax' beschrijven omdat het voor elk aparaat anders is (als ze zich aan 1 afspraak hadden gehouden net zoals bij ons lees-voorbeeld was het een stuk eenvoudiger). Ik ben een manier aan het ontwikkelen waarmee het programma kan achterhalen wat de BETEKENIS is van de inhoud van een SysEx bericht door de bytes uit het SysEx bericht te interpreteren aan de hand van deze beschrijving.
Nadeel is echter dat er voor elk device zo'n beschrijving gemaakt moet worden die het programma kan gebruiken. Voordeel is dan wel weer: omdat de 'taal' waarin deze beschrijvingen gemaakt worden WEL weer vastgelegd is (en het programma functionaliteit heeft ingebakken die daarmee om kan gaan) kan de 'rest' (bijv. schermen) behoorlijk automatisch gaan.
Ik snap dat sommige van jullie nog wat sceptisch blijven over de haalbaarheid van dit hele verhaal. Ik heb echter zelf alle vertrouwen in het principe en de ingeslagen richting. Er zullen nog zeker momenten komen waar ik 'problemen' tegen kom die ik niet had (kunnen) voorzien, maar de code is erg flexibel en uitbreidbaar opgezet.
Op dit moment ben ik bezig met het schrijven van een test applicatie voor mijn U-220. De SysEx beschrijving-afhandeling werkt nu goed (getest met de U-220) en ik ga nu kijken hoe het zich houdt in een 'echte' applicatie. Het wordt een 'hard-coded' applicatie - niks waarmee je schermen ofzo kan ontwerpen. Het is mijn bedoeling een applicatie te maken waarmee ik zo ook andere 'beschrijvingen' kan gaan testen.
Child of arT
Ouwe rot
ik wil checken of ik het nog steeds door heb...
Dus het is zo dat bij de ene synth de Sysex-taal anders kan zijn dan bij een andere synth. Het is dus geen universele taal, Sysex, die bij iedere synth hetzelfde is.
Dus het is zo dat bij de ene synth de Sysex-taal anders kan zijn dan bij een andere synth. Het is dus geen universele taal, Sysex, die bij iedere synth hetzelfde is.
DarkChaos
just music
Je idee is top.. maar...
De manier van sysex implementatie en de eventuele bovenliggende protocol laag verschillen per merk/leverancier, dit is dus sterk dynamisch. De Roland U-XXX series zijn relatief makkelijk te interfacen, maar pak bijvoorbeeld eens een TC Fireworxx.. dat is andere koek. Ik betwijfel dan ook of het nuttig is hier een 2e taal/scripting om heen te gaan schrijven. Zulke dynamische mechanisme's in zo'n high level (eigen) taaltje zijn naar mijn ervaring geen pretje. Je zult een hoop docs/functionele specificatie documenten moeten gaan schrijven alvorens er ook maar iemand zijn eigen apparaat kan toevoegen. Ik heb me in het verleden ook bezig gehouden met dit soort projecten en dat liep helaas altijd uit in een flop.
En dan niet in het technische gedeelte, maar het fatsoenlijk beschikbaar maken voor 3en. Het idee is leuk, maar vergis je niet in de complexiteit en alle bijkomende zaken (website, docs, support, forums etc etc etc)Mocht je het dan toch gaan doen, programmeer dan een VST en niet een standalone app. Niemand heeft iets aan een applicatie waarmee hij z'n midi poorten niet kan benaderen terwijl je sequencer open staat.
En over de eerder genoemde opmerkingen over .NET. Dit soort programma's zijn prima te maken in .NET. Check VST.NET maar eens. En wie heeft er tegenwoordig nu geen .NET framework op z'n computer, bijna alle microsoft applicaties vereisen dit. Dit neemt niet weg dat mijn persoonlijke voorkeur altijd uit zal gaan naar ANSI C++, simpelweg wegens de compacte binaires, efficient resource gebruik en uitvoer snelheid.
Aan de andere kant heb ik wel weer zin in een programmeer project haha, je kunt me natuurlijk altijd even pm'n als je echt serieus goeie ideeen hebt
Laatst gewijzigd:
bronswerk
nog steeds lid
Idd, die TC Fireworx is een goed voorbeeld waarbij de sysex strings dynamisch (varieerende lengte) zijn, afhankelijk van de gekozen configuaratie. Dit is vrijwel niet te ondervangen met "universele" ontworpen software. Zelfs de oeroude DX7 hanteert verschillende lengtes voor een patch, afhankelijk van het feit of ze zelfstandig zijn of onderdeel van een bank (is gecomprimeerde vorm). En de DX7 is dan nog relatief simpel. Nee, ik weet wel waarom die software fabrikanten hier niet hun neus aan stoten, it's a jungle out there.
Child of arT
Ouwe rot
Maar als het hem wel lukt om al deze barrières te doorbreken en goed te krijgen in zijn programma, dan heeft hij ook echt iets.
DarkChaos
just music
obiwanjacobi
Ingeburgerd
- Lid sinds
- 22 oktober 2012
- Berichten
- 75
Ik kan nu de Roland Address-Map aan. Dat is ook een dynamisch berichten formaat, Als ik even snel door de SysEx specs van de Fireworx kijk, zie ik zo snel niet wat er heel moeilijk / anders aan is... Misschien kan je me hiermee helpen.
Ik zal het zelf nog eens nader in detail bekijken.
Verrek! Bij VST.NET zit ook een obiwanjacobi!? :-P
Als jullie nog meer devices weten die lastig zijn, hoor ik daar heeeeeel graag van (liefst met link naar sysex docs). Hoe eerder in het ontwikkelproces ik alle verschillen boven water heb hoe sneller/makkelijker het is.
Voor beta testers is het nogwat vroeg, maar ik heb wel een aanverwant idee.
Natuurlijk kan ik nooit alle hardware aanschaffen om echte tests uit te kunnen voeren tegen het apparaat zelf. Zouden jullie ervoor open staan om een stukje software te installeren op een pc waar een van je synths (of anders) op is aangesloten (via MIDI) waarmee je mij in staat steld om remote tegen je device over MIDI te praten.
Uiteraard zou dit betekenen dat je mijn software moet vertrouwen - dat ik geen narigheid uithaal op je PC - en dat beloof ik bij deze. Maar zou je ervoor open staan om zo mij te helpen de beschrijvingen van een aparaat dat jij hebt te kunnen testen??
Ik zal het zelf nog eens nader in detail bekijken.
Verrek! Bij VST.NET zit ook een obiwanjacobi!? :-P
Als jullie nog meer devices weten die lastig zijn, hoor ik daar heeeeeel graag van (liefst met link naar sysex docs). Hoe eerder in het ontwikkelproces ik alle verschillen boven water heb hoe sneller/makkelijker het is.
Voor beta testers is het nogwat vroeg, maar ik heb wel een aanverwant idee.
Natuurlijk kan ik nooit alle hardware aanschaffen om echte tests uit te kunnen voeren tegen het apparaat zelf. Zouden jullie ervoor open staan om een stukje software te installeren op een pc waar een van je synths (of anders) op is aangesloten (via MIDI) waarmee je mij in staat steld om remote tegen je device over MIDI te praten.
Uiteraard zou dit betekenen dat je mijn software moet vertrouwen - dat ik geen narigheid uithaal op je PC - en dat beloof ik bij deze. Maar zou je ervoor open staan om zo mij te helpen de beschrijvingen van een aparaat dat jij hebt te kunnen testen??
obiwanjacobi
Ingeburgerd
- Lid sinds
- 22 oktober 2012
- Berichten
- 75
Klopt! Het enige dat hetzelfde is, is de eerste byte (F0) en de laatste (F7). Elke byte ertussen moet een waarde hebben van < 128 (hoogste bit is 0). Dat zijn de enige regels die zijn opgelegd door het MIDI protocol.
Er bestaan nog wel een aantal andere 'best practices' maar die zijn niet verplicht.
Voor elk device moet ik dus gaan beschrijven wat de betekenis is van elke byte (soms tot op bits!) binnen elk SysEx bericht. Een enkel device kan ook meerdere berichten ondersteunen. Als je eenmaal een gereedschapkist met de juiste 'tools' hebt (kleine stukjes ingebakken kennis die weten hoe bepaalde data geinterpreteerd moet worden) wordt het beschrijven van een SysEx bericht best eenvoudig. Belangrijk nu is om zoveel mogelijk verschillen (en overeenkomsten) tussen de diverse implementaties te ontdekken zodat ik mijn gereedschapkist zo effectief mogelijk kan uitrusten.
Aan de andere kant moeten we ook niet in een 'analysis paralysis' (analyze verlamming) komen. De echte kennis doe je toch pas op met de ervaring. Dus snel iets hebben waarmee je die ervaring kan gaan opdoen is ook een belangrijk punt.
DarkChaos
just music
Ben jij niet heel toevallig de leadprogrammer achter VST.NET? Want die resource DLL's bevinden zich ook in de namespace Jacobi.
Ik wil mijn ca 30 synths + FX modules best ter beschikking stellen. ik kan wel een midi in en out poortje doorrouten naar een TCP/IP socket ofzo.
Zolang je maar geen magische firmware write of factory default commando's gaat afvuren
obiwanjacobi
Ingeburgerd
- Lid sinds
- 22 oktober 2012
- Berichten
- 75
Ik wil mijn ca 30 synths + FX modules best ter beschikking stellen. ik kan wel een midi in en out poortje doorrouten naar een TCP/IP socket ofzo.
Zolang je maar geen magische firmware write of factory default commando's gaat afvuren
Moet ook getest worden! Nee, geintje hoor. Hoewel het maken van een complete backup zeker een must is,
Ik dacht aan een klein appje waarmee je de midi poorten kan instellen en vervolgens met een knop verbinding met mij kan maken. Ik heb dan mijn firewall open op een raar poortje en kan dan op de terugweg commandos opgeven (literal sysex waarschijnlijk). De gebruiker (eigenaar van de spullen) kan op elk (on)gewenst moment de verbinding weer verbreken. Ik kan op het appje log venstertjes maken waarmee je kan zien wat ik stuur en ontvang...
Maar een fase daarvoor is dat gebruikers mij bulk dumps (van elke sysex message) toesturen waarmee ik 'droog' kan testen, da's iig al een stuk laagdrempeliger.
DarkChaos
just music
Stuur me maar even een PM als je zover bent!
audiocollage
Ouwe rot
- Lid sinds
- 30 april 2009
- Berichten
- 3.158
'literal sysex' wat moet dat dan wel voorstellen ?
Welke garanties kan jij geven, wanneer je op die manier met anderen hun hardware gaat experimenteren ? Iets wat fabrikanten zelf al flink afraden !
Ik begrijp niet waarom je nog een 'midi-internet-verbinding' nodig hebt als je de bulk dumps al hebt ?
Child of arT
Ouwe rot
Ik haak af als beta-tester, ik weet te weinig van de materie af. Ik zal nooit een toegevoegde waarde zijn in het geheel van het testingsproces.
obiwanjacobi
Ingeburgerd
- Lid sinds
- 22 oktober 2012
- Berichten
- 75
Je kan altijd helpen door van je devices diverse SysEx dumps (liefst van elk type bericht eentje) naar file te saven (.syx) en die aan mij op te sturen, het liefst met (een link naar) de sysex specificaties erbij. Als je geen programma hebt die dat kan, kan je gratis MIDI-OX downloaden en installeren. Daarmee is redelijk simpel deze actie te doen (gebruik ik zelf ook).
Die dump bestanden kan ik dan gebruiken om de sysex beschrijvingen mee te testen.
@audiocollage: Het kan handig zijn om remote bij (andermans) hardware te kunnen wanneer er ondanks alle tests het toch niet werkt met het apparaat zelf. Maar we lopen erg op de zaken vooruit. Voorlopig zijn dumps idd prima!
Ik heb inmiddels nog wat SysEx specificatie documenten van diverse devices weten te verzamelen (maar nog niet geanaliseerd). Maar ik hou me nog steeds aanbevolen voor suggesties van devices die specifiek lastig of raar in hun SysEx jasje steken...
Bedankt!
audiocollage
Ouwe rot
- Lid sinds
- 30 april 2009
- Berichten
- 3.158
@obiwanjacobi zorg dat je op een of andere wijze over SD (of Midi Quest) kan beschikken en gebruik deze wijze tip.
Zodoende heb je ineens honderden kant en klare editors ter beschikking, waarvan je alles kan overnemen wat nodig is.
Dat remote gedoe ... ik geloof er niet in.
(Verder : een auto bouw je met behulp van mecaniekers niet met chauffeurs.)
een auto wordt wel ontworpen naar de behoeften van chauffeurs en er zijn test coureurs vroeg in het process betrokken. Daarbij heeft hij dumps nodig.
link naar Sysex pdf (van Sunny Pedaal)
link naar Sysex pdf (van Sunny Pedaal)
