quo vadis, bon2?
einleitung
auf dieser seite dreht es sich um ein projekt, welches eni und ich besprochen haben; in seinen ansätzen wird es auf dem konzept von bot2 fuß fassen, und dieses zu gegebener zeit sogar ersetzen (was es da zu ersetzten gibt, komplett nutzbar war bot2 so oder so nicht). kommentare aus aller welt sind natürlich wilkommen.
die idee ist es, en netpd-kompatibles patchsystem zu entwickeln, welches auf mehreren kanälen verschiedene instrument-effekt-ketten aufbauen kann, welche dann über einen sequencer und einen arranger kontrolliert werden können.
als namen für instrumente und effekte haben eni und ich uns auf module geeinigt. nach bot2-philosophie ist ein instrument nur eine unterform eines effektes.
desweiteren wäre es edel, die module zur komfortableren auswahl in kategorien zu unterteilen. genaue details, wie module geladen werden sollten und wie der creator eingebunden wird sind zur zeit in diskussion.
vorläufige roadmap
die reihenfolge ist nur sehr grob, und viele dinge können auch parallel bearbeitet werden.
M steht für eher willkürlich gesetzte meilensteine, zeit für ein glas sekt
- bedeutet geplantes feature feature
+ bedeutet feature, an dem gerade gearbeitet wird
* bedeutet komplettiertes feature
? steht für diskussionsbedürftige features, siehe unten für den diskussionsteil
* grundkonzept, erstellen einer roadmap ;)
* grafisches mockup, designvorschläge
+ entgültiges interfacedesign modulblock (nur gui)
M- entgültiges interfacedesign modulblock (auch code, alle scrollpanels und so)
- coden der ersten globalen features, (transport panel, kompatibel mit netpd's master.pd)
+ coden des lokalen grundgerüstes für dynamische abstractions
- netzladefähigkeit für dynamische abstractions
- dsp-grundgerüst, serielle audiokette
M- erstes sinustonmodul, dynamisch über das netz geladen
?- konzipierung der "controller" (slider für die instrumente)
to be continued later, mit sequenzer- und arrangerplanung.
diskussionsteil
thema controller/sequencer/automatisierung
wenn jemand fragt, wo es hin gehen soll, sagen wir stolz: jeder controller soll automatisierbar sein. sollte das wirklich so sein? oder sollte man sequenzen nur auf vermeintlich "sinnvolle" parameter beschränken, damit kein informatorischer overload entsteht? desweiteren wird es parameter geben, die zwar als sequenz bestehen, aber nicht als eigentliche controller eines moduls, beispiel trigger und noten. //syntax
die möglichkeit alle parameter zu steuern hat definitiv seinen charm. im fall des distortion macht es da sinn alles kontrollieren zu können? verlieren / gibt es nachteile wenn man alles automatisieren kann? könnte man es vielleicht so bauen dass wenn man nicht automatisiert, keine unnützen daten gespeichert werden müssen? //eni
ich dachte nur an so sachen, wenn wir zum beispiel synth2 portieren würden, der hat über 50 controller. macht es da wirklich sinn den internen signalfluss (die gotos) live automatisieren zu können? //syntax
nomen est omen
namensvorschläge und grausige geek-akronyme:
bon2 - bag of netpd 2
bonbon - (bag of netpd)^2
esc - eni's + syntax' composer (nerdige anspielung auf "escape"
secs - syntax' + eni's composer software (nerdige anspielung zu "sex", aber pd hat mit zexy schon eine solche, was sollen neue user dann nur denken...)
oranje composer - funktioniert nur, wenn das gui wirklich orange bleibt
vielleicht ein schöner städtename:
historisch: babylon, jericho, angkor, troy
modern: brasilia, tokyo, paris (wobei, da gibts oft zu viele negative assoziationen, paris hilton oder tokyo hotel...
was schickes aus der wissenschaft ist immer beliebt: neutron, virus, tau, d-brane, conductor (nettes wortspiel leiterelement/dirigent), sol, delta, aber ich befürchte, die schiene ist für synth und software-namen schon zu abgegrast
etwas sprachliches vielleicht: syntax ;), semantix, singular, phonem, silentia
oder was ganz anderes: starfish, jesus, etcpp