okay, ik ben al sedert enige tijd bezig met een vj-tool achtig iets, puur voor de lol. dit programma genereert realtime 3d-beelden die in de toekomst reageren op de muziek. ondertussen ben ik zo ver dat ik allerlei vormen op mijn scherm kan toveren, die in verschillende matrices kan zetten, er controllers op kan zetten en nog wat andere geinige dingen doen, zonder de boel te laten crashen. de engine is dus al behoorlijk gevorderd en het word tijd om de gui in elkaar te zetten. hier volgt een probleem waar ik al een tijd mee worstel in mijn hoofd.
het komt erop neer dat ik mn prog zo flexibel mogelijk wil houden. daarnaast moet het makkelijk blijven om nieuwe generatoren, effecten etc etc toe te blijven voegen. hier volgt het probleem: ik kan nu nog niet voorspellen welke en hoeveel parameters die nieuwe dingen zullen hebben. voorbeeldje: bij mijn cirkel generator kun je alleen de radius instellen, maar bij mijn atoom generator kun je aantallen elektronen, bewegingspatronen, cirkelradiussen en nog veel meer instellen. toch wil ik al die parameters op een envoudige manier allemaal via dezelfde gui willen aansturen.
ik heb de volgende oplossing bedacht: iedere generator krijgt een ReturnInterface-methode. deze methode retourneert een object met een vector. deze bevat vector voor iedere parameter de volgende gegevens:
- een pointer naar de methode waarmee de parameter in te stellen is (een pointer naar SetRadius of SetElectronCount bijv)
- wat voor type heeft de parameter? is het een float of of een integer of een string? (lijkt me dat dit met een enum gedaan moet worden)
- de minimale, de maximale, de standaard en de huidige waarde voor de parameter
is dit een goed idee of moet ik het over een heel andere boeg gooien? ik heb totnutoe alleen nog maar over het probleem gefilosofeerd en nog niks geimplementeert dus als het een slecht idee is, is het nu nog niet te laat
dan is er nog een laatste implementatie kwestie... laat ik mn dialoogschermen zelf direct met de pointers naar de functies werken of doe ik er nog een laag tussen in het object wat ik hiervoor beschreef? het voordeel van het laatste is dat je minder kans hebt op segmentation errors lijkt mij. aan de andere kant als je het goed doet zou je die moeten kunnen uitsluiten en ik denk dat de eerste methode een stuk sneller is.
en aangezien ik toch al zo'n lange lap tekst heb getikt nog een laatste vraag: hoe moeilijk is dit proces te automatiseren? niet dat het echt moeilijk is om voor alles zo'n ReturnInterface-methode te schrijven maar misschien dat met een template oid het automatisch te doen is?
anyway, bedankt voor het lezen van deze lange lap tekst
het komt erop neer dat ik mn prog zo flexibel mogelijk wil houden. daarnaast moet het makkelijk blijven om nieuwe generatoren, effecten etc etc toe te blijven voegen. hier volgt het probleem: ik kan nu nog niet voorspellen welke en hoeveel parameters die nieuwe dingen zullen hebben. voorbeeldje: bij mijn cirkel generator kun je alleen de radius instellen, maar bij mijn atoom generator kun je aantallen elektronen, bewegingspatronen, cirkelradiussen en nog veel meer instellen. toch wil ik al die parameters op een envoudige manier allemaal via dezelfde gui willen aansturen.
ik heb de volgende oplossing bedacht: iedere generator krijgt een ReturnInterface-methode. deze methode retourneert een object met een vector. deze bevat vector voor iedere parameter de volgende gegevens:
- een pointer naar de methode waarmee de parameter in te stellen is (een pointer naar SetRadius of SetElectronCount bijv)
- wat voor type heeft de parameter? is het een float of of een integer of een string? (lijkt me dat dit met een enum gedaan moet worden)
- de minimale, de maximale, de standaard en de huidige waarde voor de parameter
is dit een goed idee of moet ik het over een heel andere boeg gooien? ik heb totnutoe alleen nog maar over het probleem gefilosofeerd en nog niks geimplementeert dus als het een slecht idee is, is het nu nog niet te laat
dan is er nog een laatste implementatie kwestie... laat ik mn dialoogschermen zelf direct met de pointers naar de functies werken of doe ik er nog een laag tussen in het object wat ik hiervoor beschreef? het voordeel van het laatste is dat je minder kans hebt op segmentation errors lijkt mij. aan de andere kant als je het goed doet zou je die moeten kunnen uitsluiten en ik denk dat de eerste methode een stuk sneller is.
en aangezien ik toch al zo'n lange lap tekst heb getikt nog een laatste vraag: hoe moeilijk is dit proces te automatiseren? niet dat het echt moeilijk is om voor alles zo'n ReturnInterface-methode te schrijven maar misschien dat met een template oid het automatisch te doen is?
anyway, bedankt voor het lezen van deze lange lap tekst
/u/27299/hoofd.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
)
). Ik ben zelf van plan met een buzz clone te beginnen nadat we klaar zijn met het klussen en inrichten van ons huis, als ik dus weer een beetje tijd heb om te hobby'en. Ik wil het dan ook iets uitgebreider aanpakken. In buzz is een machine gewoon iets dat een of twee kanalen geluid produceert, en evt. een of twee kanalen geluid als input heeft, met parameters die elke tick doorgevoerd worden. Dat limiteert nogal, je kunt niet iets maken dat een geluidsstream moduleert met een andere geluidsstream bijvoorbeeld, daarnaast is het editen van parameters een ramp. Als je aan elke parameter ook een parameterstream kunt binden, kun je bijvoorbeeld met standaard LFO's e.d. al hele leuke dingen doen ipv met de hand een beetje een sinusgolf in een tracker in gaan zitten tikken. Meer het Propellerhead's Reason idee dus, waar een "machine" gewoon tal van in- en outputs heeft, maar dan nog meer modulair.