analoger synthesizer soll gebaut werden...

[Moogulator]

wie gesagt. ich halte die slew rate für den wichtigen faktor.

grad noch paar mal gemessen. 0.046ms sollt schnell genug sein, oder?

das ist mal die reine VCA-slew-rate von 0 auf max amplitude bei einem einfachen rechteck am input

mehr auflösung gibt mein mac nich her zum messen, von 0 bis max sinds halt insgesamt nur 3 messpunkte laut audacity. aber der wert ist nachvollziehbar.

also zusammengefasst:

ausgehend von attack rate auf maximum, und folgender annahme:

die VCOs der voice und ihre VCAs werden programmiert, die slew rates der VCAs sind schnell genug, dass sie geladen sind, bis der ausgangs-VCA angeschmissen wird. das kann zwar gegenüber dem eigentlichen ton-start 2ms dauern, aber solange kommt auch noch kein signal raus. die VCOs sind eingeschwungen, die VCAs und VCFs und was noch alles dazwischen hängt auch, und dann kommt der ausgangs-VCA mit den 0.046ms von 0-100% und haut einem den ton um die ohren.

so. einwände?

ja, generell haben hüllkurven eine geschwindigkeit und eine kurve, beides sollte man beeinflussen können .. wäre cool..

dazu haben envs evtl bipolarität oder eben nicht.. / inv.
das ist bei geschicktem routing auch nicht immer schwer zu machen..
ein amp braucht sicher eher keine bipolare env

bei dem VCO sound hab ich irgendwie noch den eindruck ,da könnte mehr an obertönen kommen? oder liegts am mp3.. das ist halt sone sache..

16 britzel genug?
ja, imo reichen sogar 4 oder so..
ich bleib bei meiner traumvorstellung: 3 oktaven, 4-8 stimmen (realistischerweise nicht mehr).. lieber mehr für die vorhandenen stimmen.. damit komm ich klar..

noise: verschiedenfarbiges rauschen ,oder wie? wäre dann nicht eine art festfilterbank fast sinnvoller für eine quelle? ja, ich geh weiter von nichtmultitimbralität aus.. oder spezielle verschiedene krachmacher.. mal digitales gebritzel, mal samplerate eintopf und eben pulsegedenkgel..= das ist nicht übel.. besonders, wenn ein KAMMFILTER an bord ist!! ja!!!

slew und zeiten: nunja: je kürzer das GEHT desto besser, auch langsam sollte gehen.. vermutlich braucht man bereichsschalter..

1/2minute bis 0.X ms (x idealerweise klein. .aber 0.5ms ist schon sehr sehr gut.. )

 

[MiK]

Oben kommt es aber irgendwie so rüber, als ob Du doch nicht auf Filterkarten, sondern auf Festfilter setzen willst oder ich bin total verwirrt.

hm. irgendwie is das konzept glaub echt noch nicht sauber rübergekommen, ich hab immer mehr das gefühl, dass sich keiner so recht vorstellen kann, was ich da zammbau. also versuche ich mal, das gesamtbild etwas zu entwirren, vereinfachte fassung, geplante ausbaustufe der "standardversion":

1) es gibt VCOs. will man haben. 2 VCOs sind auf einem modul drauf. diese VCOs sind komplett arbeitsfähig, strom rein, signal raus. aber es fehlen einige dinge, so sind z.b. nicht massig CV-inputs drauf, sondern nur die sammelschiene des CV-summierverstärkers. bei beiden CVs, also linear und exponentiell. außerdem fallen einfach 5 wellenformen vom VCO selber und 4 wellenformen vom subosc raus. entsprechend das ganze zweimal. außerdem gehen da noch ne CV für den CV scaler rein, der die feinanpassung auf 1V/oct macht, und die pulsweite. außerdem gibts nen sync ausgang und eingang. auch doppelt, klar. von diesen modulen sollen 8 stück rein, also 16 VCOs. lassen wir das mal so im raum stehen.

2) es gibt VCO controller. will man auch haben. da ist der rest drauf, der nicht auf dem VCO-modul drauf ist. also die eingangswiderstände für die CV-summierer, außerdem einige analogschalter, die die 5 hauptwellenformen einmal auf einen ausgangs-VCA (exp) für audio mixen (also 32 möglichkeiten, wobei nicht alle sinn machen), außerdem werden die 5 wellenformen zusätzlich noch auf einen anderen ausgangs-VCA gemixt (der ist lin) für modulationszwecke. und dann waren da noch die 4 outputs des subosc, mit denen passiert das gleiche, aber nicht für modulation, der bekommt nur nen audio-VCA dran. außerdem sind auf dem controller noch einige analogschalter, die von insgesamt 16 mod-eingängen auf die linear oder exponentielle CV des VCO greifen können. das ist für jeden eingang umschaltbar, und alles wird zusammengemixt auf 2 VCAs, der einige geht auf lin, der andere auf exp. gut. haben wir 16 modulationseingänge und einen modulationsausgang. gruppieren wir 8 VCOs zusammen, also die hälfte. damit sind die ersten 8 modulationsbusse zwischen diesen 8 VCOs belegt, ich kann also jeden mit jedem modulieren, auch 2 VCOs benutzen, um einen zu modulieren, und die VCOs gehen ganz brauchbar runter, mindestens auf 0,25Hz (evtl. noch tiefer, hab das noch nicht im detail analysiert, rekord war 0,0625Hz, aber obs mit der momentanen CV-steuerung hinhaut, weiss ich net). man kann auch mit einem VCO mehrere modulieren usw. quasi 64er crosspoint-matrix, wenn man so will. die anderen 8 mid-inputs sind 8 busse, die an anderer stelle frei belegt werden können, z.b. hinterm filter oder auch mit noise und sowas. anforderung an die buseinspeisenden elemente: jede einspeisung hat dafür einen VCA (lin), wie auch die VCOs. das ist dazu da, daß sich der krempel nicht gegenseitig beeinflusst, also niedrige impedanz am ausgang, hohe am eingang, und da alle inputs summierer sind, sind alle auf 0V-potential, es wird also nix verschoben, wenn ich eine mod-quelle an mehreren stellen benutze.

konSequenz aus 1) und 2) - ich kann 1) auch ganz anders einsetzen, wenn ich statt 2) nicht analogschalter und sowas nehme, sondern ein paar widerstände, trimmer, potis, klinkenbuchsen - schon ist das ein modul für nen klassischen modularen synth. so sind alle module ausgelegt, sie können flexibel eingesetzt werden, vielleicht bau ich mir doch mal nen echten modularen draus.

2) könnte übrigens aus mehreren modulen bestehen, z.b. ein quad-expo-VCA-modul (hab ich heute morgen entwickelt) oder ein mehrfach linear-VCA-modul (entwickel ich gerade), und dazu dann das modul mit den ganzen analogschaltern.

sync wird folgendermassen verschaltet: 1->2, 2->3, 3->4 usw... 16->1
diese verbindungen sind natürlich abschaltbar. und wenn ich es für sinnvoll befinde, sind VCAs dazwischen

die 8 "universalbusse" gelten prinzipiell für die 8er-gruppe von VCOs. aber dazwischen kommt nochmal ein 8fach-analogschalter, mit dem ich diese busse auftrennen kann, also 8 busse pro 4er-gruppe. das gibt mehr möglichkeiten, wenn ich voices mit 4 VCOs aufbaue, und nicht die modulationen über 8 VCOs brauche.

dahinter kommen dann filter. insgesamt 16 stück. was da in den slots steckt, ist primär mal egal, alle haben auf jeden fall CV für cutoff und reso, dann auch CV scaling wie beim VCO, schließlich will das ding auch tuned werden, man will ja evtl. nen filter als VCO benutzen. und das geht. weil man auch hier die eingänge frei einschalten kann aus einem gewissen pool an signalen. oder eben auch nicht, womit er keinen eingang hat und als sinus-generator missbraucht werden kann. der ausgang ist dann z.b. auf einen oder mehrere dieser 8 modulationsbusse aufschaltbar. als eingangsmöglichkeiten bieten sich an: 1 bis mehrere VCOs, die zu diesem VCF gehören (also bis zu 8, wenn wir schon bei dieser gruppierung sind), und die nachbarfilter. vielleicht auch die modulationsbusse. damit kann ich filter hintereinanderschalten, um z.b. aus LP und HP nen BP zu bauen. oder um 2 LPs hintereinanderzuschalten um nen 48dB filter zu konstruieren.

übrigens will ich abgriffe für alle 4 stufen des filters, also 6, 12, 18, 24dB sind alle benutzbar.

dahinter gibts dann noch VCA-module, vermutlich 8 davon. deren eingänge sind einerseits auf die 8 VCOs schaltbar (ich will ja auch mal den filter umgehen können) und andererseits auf die filter.

so. ab hinter VCO controller ist das jetzt alles etwas schwammig und unvollständig beschrieben, weil das alles noch nicht klar definiert ist. es sind noch ringmodulatoren und so zeug mit dabei, auch diese kann man entsprechend einklinken.

hüllkurven und LFOs kommen aus der CPU (wenn man nicht nen VCO als LFO benutzt). diese werden also auf die CVs gerechnet, die von der CPU an den VCO oder sonstwas gehen, brauchen also keine modulationsbusse.

soviel zur hardware. ich hoffe, das konzept ist nun jedem klar, und jeder, der drüber nachdenkt, wird die flexibilität da drin erkennen. jetzt kommt nämlich der trick:

template 1 - 2VCO, 2VCF, 1VCA, 4LFO, 4EG:
"leg das bitte auf MIDI-kanal 1, prio 2"

template 2 - 4VCO, davon einer LFO, 4VCF, 2VCA, 8LFO, 8EG
"leg das bitte auf MIDI-kanal 2, prio 1"

template 3 - 8VCO, subtemplates FM-algorhythmus irgendwas, 8 VCF, 4VCA, 16LFO, 16EG
"leg das bitte auf MIDI-kanal 3, prio 3"

diese konfiguration angenommen (und natürlich neben den templates entsprechend alle sinnvollen parameter konfiguriert, die templates geben nur die "resourcen" der voice vor, matrix und parameter sind darin editierbar wie bei jedem "normalen" synth), spiele ich z.b. meinen bass auf kanal 2, und brauche quasi durchgehend die komplette voice, also 4 VCOs usw.
mein lead ist auf kanal 1, es können akkorde vorkommen, ich brauche bis zu 6 VCOs
auf kanal 3 hab ich ein paar lustige FM-effekte, die ich hin und wieder reinhaue.

wenn ich das jetzt übertreibe, und kanal 3 mono mit nem effekt spiele, meinen bass auf kanal 2 und nen akkord auf kanal 1, wird kanal 3 aufgrund der prio wegen resourcenengpass abgeschaltet zugunsten kanal 1 und 2. hätte ich kanal 1 auf prio 3 und kanal 3 auf prio 2 gesetzt (bzw. nicht den kanal, sondern den patch darauf, der das template benutzt), würde der effekt weiterlaufen und von meinem akkord ein ton fehlen, weil:

2x2VCO, 1x4VCO, 1x8VCO = 16VCO

so. das ist meine vision. noch fragen? im zweifelsfall einfach den ganzen thread durchlesen, ich glaub, mittlerweile hab ich echt die gesamte planung zusammengeschrieben. wenn das jetzt einer der "großen" liest, gibts das ding irgendwann von jemand anders aufm markt, bevor ich überhaupt angefangen hab, die platinen machen zu lassen für all die module. is mir dann aber auch scheissegal, ich hab trotzdem meinen spass dabei

ja. ich mal irgendwann ein bild davon. bisher hab ichs nur nicht auf nen A3-papier gekriegt.

 

[Anonymous]

Analoger Stufen-Abschwächer mit Festwiderständen

ein amp braucht sicher eher keine bipolare env

Dem Experten ist selbstverständlich klar, dass die Bezeichnung "VCA = voltage controlled amplifier" reines Bullshitting ist. Richtig ist, dass es sich bei dieser Baugruppe um einen spannungsgesteuerten Abschwächer (voltage controlled attenuator) handelt, wobei nun die Ansteuerung mittels inverser Hüllkurve mehr als sinnvoll erscheint. Muss alles umkonstruiert werden. Echt.

 

[MiK]

Dem Experten ist selbstverständlich klar, dass die Bezeichnung "VCA = voltage controled amplifier" reines Bullshitting ist. Richtig ist, dass es sich bei dieser Baugruppe um einen spannungsgesteuerten Abschwächer (voltage controlled attenuator) handelt, wobei nun die Ansteuerung mittels inverser Hüllkurve mehr als sinnvoll erscheint. Muss alles umkonstruiert werden. Echt.

genau deswegen hab ich drauf geachtet, dass hinten mehr rauskommen kann als vorne rein. im prinzip ist es ja beides. schön, dass das A sowohl für amplifier als auch für attenuator passt.

übrigens wäre obige baugruppe, wenn auch nicht schnell, in verbindung mit einem schrittmotor ein stylishes bauteil für mein projekt

 

[Moogulator]

Analoger Stufen-Abschwächer mit Festwiderständen

ein amp braucht sicher eher keine bipolare env

Dem Experten ist selbstverständlich klar, dass die Bezeichnung "VCA = voltage controlled amplifier" reines Bullshitting ist. Richtig ist, dass es sich bei dieser Baugruppe um einen spannungsgesteuerten Abschwächer (voltage controlled attenuator) handelt, wobei nun die Ansteuerung mittels inverser Hüllkurve mehr als sinnvoll erscheint. Muss alles umkonstruiert werden. Echt.

der einwand ist berechtigt, besonders wenn wir das zugrunde legen ,was initial VCA heisst..

die frage ist nur: reicht es in diesem system nicht, von einem nullpunkt = stille auszugehen ? macht es sinn ,wenn nach releasephase mehr als null rauskommen könnte?.. macht es sinn, wenn das vor der hüllkurve so ist?

ok, schon falsch: dabei gehen wir ja schon davon aus, dass eine fest env einen vca steuert, der sich am ende befindet.. aber: wir werden aufgrund der konzeption wohl etwas in dieser art haben.. ist idR das einfachste..

sprich: welchen vorteil hat eine bipolare env oder eine negative bei einem finalen VCA ,der als "lautstärkeformer" genutzt werden soll?..

die abschächer-problematik ist natürlich bekannt, aber gut, dass es gesagt wird..

kommentar?

 

[Anonymous]

Stereo-Panning mittels Env.-Generator. z.b.

 

[Moogulator]

das ginge aber an dem vorbei,was ich sagte.. ist ja eine konzeptfrage.
ob es ein pan gibt, ist ja noch nicht bekannt..

ich bezog mich auf einen quasi finalen VCA (einen).

 

[MiK]

stereo-output will man schon. vermutlich gibs auch 8 einzeloutputs.
und panning mach ich dann über 2 VCAs, das ist handlich in software zu machen, in elektronik wäre es etwas bloated, hatte das heute erst durchdacht bei dem gedanken, den VCA-grundkern auch für ringmod zu verwenden. da musst dann, wenn negative CV kommt, ne menge anderes zeug invertieren und so, ist unterm strich nicht so sauber, denke ich.

beim exp VCA, den ich jetzt gebaut hab, hab ich regelbereich -10V bis +10V (bzw. bissl drüber hinaus), also volle 16bit für 0-max.

nur der lineare VCA zickt noch, bin nimmer zum weiterentwickeln gekommen, weil ich hier permanent am posten bin. hölle, was da für traffic herrscht

so. feierabend für heute -> sofa.

 

[Moogulator]

ok, das dachte ich mir dann auch.. 2 VCAs ,
obwohl pan steuerung einfacher mit bipolaren envs ist..

finale VCAs sollten schon lin oder exp sein können.. hat beides seinen sinn..

template2: hmm ,da gibts keine FM zwischen den VCOs? oder doch?
macht FM mit 8 VCOs sinn? sprich: sind sie phasensteuerbar? wenn nicht, braucht man diese anzahl vermutlich nicht , zumindest nicht für exakte FM..

ich finde das aber gut und entspricht vielen wünschen..
da die anzahl konstant bleibt ,wird das klar, was da an porzessorpower rein muss..

die ganzen hübe und routings müsste man noch checken.. die softsachen sind evtl einfacher und die mods können im rechner zusammengefast werden, so wäre das mit dem hub technisch rel. einfach..

ja, da haste dir was vorgenommen..
das modkonzept und die form und möglichkeiten der LFOs und ENVs stehen fest?

phasensteuerung der VCOs? (schätze eher nicht, oder)?

 

[MiK]

ok, das dachte ich mir dann auch.. 2 VCAs ,
obwohl pan steuerung einfacher mit bipolaren envs ist..

du denkst noch nicht abstrakt genug

also 2 VCAs nicht. 8 oder 10. je nachdem, wie ich die outputs organisier, ob ich einfach nur 8 mache oder 8 einzeln zuweisbare und 2 für normal stereo. eher ersteres, weil ich dann ja auch 2 von den 8 als stereooutput benutzen kann.

und von wegen bipolare envs - kann ja für den user so aussehen. was intern passiert, geht den dann im endeffekt nix an. ich denke im moment noch in hardware, was das design angeht. in software kann man das dann ganz anders aussehen lassen.

finale VCAs sollten schon lin oder exp sein können.. hat beides seinen sinn..

solange die finalen reichen, hab ich da keine schmerzen mit. der exp VCA ist nämlich nicht wirklich linear sauber zu bändigen, drum gibts nen dedizierten lin VCA. würde am ausgang für jeden output beide VCAs bedeuten. das ist machbar. aber zwischendrin bleibt strikt die regel - exp für audio, lin für mod.

wobei ich in software (mit einem gewissen rechenaufwand) nen lin-VCA exp ansteuern kann. das setze ich vielleicht an der einen oder anderen stelle noch ein, aber umgekehrt geht nicht so einfach.

template2: hmm ,da gibts keine FM zwischen den VCOs? oder doch?
macht FM mit 8 VCOs sinn? sprich: sind sie phasensteuerbar? wenn nicht, braucht man diese anzahl vermutlich nicht , zumindest nicht für exakte FM..

vorsicht! das sind nur 3 beispiele. halte dich nicht dran fest. templates kann man gestalten, wie man will. nimm halt template4, FM mit 4 oszillatoren. blah.
FM mit analogen oszillatoren macht vermutlich keinen so riesensinn. muss ich ausprobieren, wenn ich mal mindestens 4 VCOs habe. es ist halt "FM wie bei nem modularen". hab damit keine erfahrungen. phasensteuerbar sind sie nur mit hohem aufwand, das leben des sounds würde darunter auf jeden fall leiden, weil die dinger dann 100% exakt laufen würden. so wie im waldorf pulse, der zwar nicht schlecht klingt, gegenüber einem echten analogen aber doch etwas steril.
hatte ja schon mal erwähnt, daß es theoretisch möglich ist, die sync von der CPU zu steuern, womit ich einen gewissen einfluss auf die phase hätte. vielleicht mach ich das, muss das aber selber ausprobieren. die auflösung ist da natürlich dann durch die counter in der CPU begrenzt, also geht schon mal nicht alles, was man da evtl. gerne haben würde, was die sync angeht. eigene CPU dafür ist eh pflicht, das ist timingkritisch wie sau. und ich wage zu zweifeln, daß eine CPU ausreicht, 16 VCOs sauber zu syncen.

ich finde das aber gut und entspricht vielen wünschen..
da die anzahl konstant bleibt ,wird das klar, was da an porzessorpower rein muss..

jo. vor allem ist klar definiert, wo die realtime-prios liegen. drum gibts ja auch mehrere CPUs. eine alleine würde ausm takt kommen. drum gibts nen dicken TWI dazwischen (so heisst der I2C heute), 400kbps, und die CPUs haben alle spezialisierte aufgaben. einer macht nur CV-multiplexing, kümmert sich "zwischendrin" mal um den TWI, und so gibts für mehreres eigene CPUs. evtl. auch eine für EGs und eine für LFOs, wobei ich mir noch gedanken machen muss, ob ich den benefit der dedizierten rechner dafür nicht durch den erhöhten datenaustausch wieder zunichte mache. vielleicht auch multimaster, dass die EG/LFO-CPUs direkt in die CV-CPU schreiben. bei der hab ich übrigens vorhin double-buffering der CVs auf VCO-scope beschlossen, dass eine VCO-manipulation "atomar" läuft, also in z.b. 0.5ms komplett durchprogrammiert ist, und nicht ein paar parameter mitten im run geändert werden und das am end noch hörbar ist, weil grad der VCO gescannt wurde.

die ganzen hübe und routings müsste man noch checken.. die softsachen sind evtl einfacher und die mods können im rechner zusammengefast werden, so wäre das mit dem hub technisch rel. einfach..

aber im rechner hab ich nur eine begrenzte verarbeitungsgeschwindigkeit, bedingt durch ADC und den CV-multiplexer. drum will ich so viel wie möglich wirklich physikalisch routen. nur der kram, der von der CPU generiert wird, und vielleicht noch S&H, wird auf CPU-basis laufen.

ja, da haste dir was vorgenommen..
das modkonzept und die form und möglichkeiten der LFOs und ENVs stehen fest?

ja. is nich wenig akt. vollversion mal irgendwann grob geschätzt 60-70 so module wie der VCO, den ich ja gepostet hab (übrigens sind die bilder jetzt updated und etwas besser).

das modkonzept steht "grob" fest. sind nur einige randbedingungen, die die module erfüllen sollen, siehe grosser post mit der beschreibung. nicht alle module brauchen das erfüllen, weil einige module einfach CPU-anbindung sind und damit keinen anderen einsatzzweck erfüllen müssen. es gibt auch kein genormtes pinout, ich kann also keinen filter in nen vco-sockel stecken und so spielchen. man solls ja kaum glauben, aber die 50 pins von dem doppel-VCO-modul sind weitgehend mit funktionen vollgestopft. drum gibts auch kein "generisches pinout" und ein echtes bussystem dahinter.

und LFOs und ENVs stehen im moment nur in einem punkt fest: es wird sie geben
das ist software. kommt viel später. was die dann können, hängt von der anzahl verbratener taktzyklen in der CPU und von der anzahl CPUs dafür ab. insgesamt wirds vermutlich 32 LFOs und 32 EGs geben. also doppelt so viele wie VCOs. das wäre mit ner 2VCO-voice 4 LFOs und 4EGs für die voice. sollte ausreichen. übrigens bekommen die VCOs einer voice alle nochmal ne eigene hüllkurve, eigentlich hat da jeder kleinkram ne hüllkurve, wenn er denn will. mag man haben.

phasensteuerung der VCOs? (schätze eher nicht, oder)?

siehe oben. theoretisch machbar, aber eklig zu implementieren. ich sehs aber im VCO controller auf jeden fall mal vor, dass es in der hardware auf jeden fall sync-input von den VCOs auch an der CPU gibt. wer weiss, wann mans mal brauchen kann.

 

[Moogulator]

vielleicht nur einen teil der VCOs phasensteuerbar? das wäre auch denkbar?..

abstrakt: krieg ich schon hin..
ein paning mit monoquelle ist imo begrenzt interessant, evtl vorhandene modquellen dafür nutzen.. naja.. hier muss man überlegen ,was da was bringt.. ich gehe davon aus ,das das noch nicht klar ist..

bipolar envs als generelle modquelle kann man machen.. ansonsten könnte man das auch beim ziel umdrehen.. dann wäre das garnicht nötig..

lineare fm mod: tja ,das brauchen wir dann schon..
und wenn die fm was bringen soll ,müssen auch die fm amounts irgendwo moduliert werden, sonst wirds irgendwann nur ein riesengeschwaber..

es gibt sachen, wo die kennlinen ne menge beitragen können..

template: ok, ich wollte ja nur wissen ,wie "fest" das ist..
fm mit bis 4 vcos ist noch interessant.. mehr ist one phasensteuerung eher nicht mehr sinnvoll, besonders ,wenn die einzelnen fm amounts zum nächsten VCO nicht steuerbar ist.. da brauchen wir doch schonwieder VCAs?..

da reichen auch nur ein paar, nicht für alle..
ungenaue fm mod geht ja auch..

aus erfahrung mit moog und roland VCOs kann ich sagen: 4 fach mod ist ok, aber nicht mehr so gezielt, da die dinger ja alle freilaufend sind..

nunja, phasensteuerung ist free oder einstellbar in grad.. so stell ich mir das vor.. ich denke eine mischform ist akzeptabel.. sehr sogar.. analoge phasensteuerung gibts nicht viel..

sync: aaanderes thema: softsync wäre fein.. steuerbar ist auch gut.. wie genau?

sync: denke ,das wird man ebenso nicht bei allen brauchen.. aber auch hier ist das eine frage der durchgängigkeit und der konzepte.. ich finde es nicht schlimm, wenn man die sache bei den selten genutzten dingen etwas reduziert.. 16 syncende VCOs brauchte ich bisher selten ..
aber ich darf sicher nicht von mir allein ausgehen..

mit dem scanning und co muss man vermutlich experiementieren ,was da durchhält und wie gut die mod dann noch ist.. so siehst wohl aus?..

den s&h auf prozessor geht vielleicht beim takten, bei der slew auch?

wie stabil sind denn die vcos eigentlich? braucht es eine autotune-routine?

der multiplexer wird ein problem, oder? bei schnellen modquellen..
du hast sicher mehr ahnung dabei als ich.. ich kann mir das aber vorstellen.

kleinkram: jo, die anzahl ist fein.. zumal man sich ja noch umentscheiden kann und das ganze noch verdoppeln.. nur: sind die routings dann andere oder quasi so gerorutet, als wärs noch ein mehrstimmen synth..

 

[Tom]

ggf. lieber 6 Stimmen die fett und "schnell" sind als 8 die nur mittelmässig daher kommen.

Also ich seh das wie der Moogulator und wäre mit 4 Stimmen schon zufrieden, mehr ist zwar schön muss aber nicht.

Ok, 4 stimmig ist sicherlich auch in Ordnung vor allem wenn ein evtl. analog Delay oder Chorus eingebaut wird

Ich bin bis jetzt immer von 16 OSCs = 8 stimmig bzw. 2OSCs pro Stimme ausgegangen. Aber das Grundkonzept ist ja jetzt wohl festgezurrt.

 

[MiK]

vielleicht nur einen teil der VCOs phasensteuerbar? das wäre auch denkbar?..

gleiches recht für alle. vereinfacht die dynamische zuteilung, die ich bei dem modell wirklich brauche. alleine schon die gruppierung bringt da so ihre probleme mit sich. theoretisch könnte ich ja mit 16 VCOs 5 stimmen zu 3 VCOs parallel machen. geht aber nicht, durch die gruppierung würden mir da einige modulationswege verloren gehen. also nur 4 3er und dazu noch 2 2er.

im extremfall selektiv. 8 syncers, die ich auf 8 VCOs legen kann von den 16. dann z.b. auch 4 links, 4 rechts oder wie auch immer. diese ganze verbindungsthematik ist insgesamt noch etwas schwammig. erstmal bau ich dir grundkomponenten, verdrahtet wird im moment aufm breadboard, und wenn da dann mal ein brauchbares resultat rausfällt, dann gehts an die automatisierung.

ein paning mit monoquelle ist imo begrenzt interessant, evtl vorhandene modquellen dafür nutzen.. naja.. hier muss man überlegen ,was da was bringt.. ich gehe davon aus ,das das noch nicht klar ist..

exakt. aber mir ist grad eingefallen, wozu ich am ausgang auch linear-VCAs brauche - z.b. fürs panning vermutlich schalte ich pro ausgang einfach nen linearen und nen exponentiellen hintereinander. der eine macht panning und was sonst noch so an zweck für linear einfällt, der andere kümmert sich um den eigentlichen ausgangspegel.

bipolar envs als generelle modquelle kann man machen.. ansonsten könnte man das auch beim ziel umdrehen.. dann wäre das garnicht nötig..

das macht die software. die hardware wird "dumm", handlich, effizient, alles, was in software ohne gross rechenleistung abgebildet werden kann, kommt da hin.

lineare fm mod: tja ,das brauchen wir dann schon..
und wenn die fm was bringen soll ,müssen auch die fm amounts irgendwo moduliert werden, sonst wirds irgendwann nur ein riesengeschwaber..

is ja drin. siehe dicker post. modulationslevel ist an ausgang und eingang von jedem VCO regelbar, modulationen können sowohl auf linear als auch exponentiell geschaltet werden.

template: ok, ich wollte ja nur wissen ,wie "fest" das ist..

"expert mode" - da kommt man an alles ran.

fm mit bis 4 vcos ist noch interessant.. mehr ist one phasensteuerung eher nicht mehr sinnvoll, besonders ,wenn die einzelnen fm amounts zum nächsten VCO nicht steuerbar ist.. da brauchen wir doch schonwieder VCAs?..

sind drin.

da reichen auch nur ein paar, nicht für alle..
ungenaue fm mod geht ja auch..

ja, im prinzip ists flexibel genug, auf 1:n und n:1 modulationen passt mein modell. bei n:n wirds dann unentspannt

nunja, phasensteuerung ist free oder einstellbar in grad.. so stell ich mir das vor.. ich denke eine mischform ist akzeptabel.. sehr sogar.. analoge phasensteuerung gibts nicht viel..

weiss ich auch nicht, ob das wirklich so machbar ist. technisch siehts so aus, dass ich den sync halt von der CPU an jeder beliebigen stelle der wellenform abschiessen kann, damit erreiche ich dann die phasensteuerung. streng genommen, im verhältnis zu den anderen wellenvormen, kommt da ja auch kein sinus sondern ein cosinus raus. auf jeden fall ist das 90 oder 270 grad verschoben.

sync: aaanderes thema: softsync wäre fein.. steuerbar ist auch gut.. wie genau?

das ist der "vielleicht bau ich nen VCA in die sync". muss schauen, ob das in der richtung hilft. ich hab immerhin jetzt mal endlich ne satte hard sync hinbekommen, die zuverlässig tut. alles davor war sowas wie soft, wobei ich das thema bisher noch nicht ganz im detail durchgelesen habe. mein sync ist auf jeden fall mal ein waveform-reset, also entladen vom ramp des saw-generators. das passiert durch kurzes senken der referenz für toplevel der amplitude. mit nem VCA könnte ich da die absenkung kleiner machen, also nicht runter auf 0V, dass es immer triggert, sondern etwas höher, dann triggerts nur in bestimmten bedingungen. aber so echte softsync ist das glaub nicht.

sync: denke ,das wird man ebenso nicht bei allen brauchen.. aber auch hier ist das eine frage der durchgängigkeit und der konzepte.. ich finde es nicht schlimm, wenn man die sache bei den selten genutzten dingen etwas reduziert.. 16 syncende VCOs brauchte ich bisher selten ..
aber ich darf sicher nicht von mir allein ausgehen..

braucht niemand. aber die verschaltung ist da. weil die CPU ja vielleicht entscheidet "hm. da will jemand nen ton mit 4 VCOs machen, von denen 1 und 2 synced sind, ich nehm mal VCO 8, 9, 10, 11 dafür", dann muss die 1->2 verschaltung entsprechend transportiert werden auf 8->9. drum brauch ich das auf allen VCOs. aber so richtig cross sync in alle richtungen mach ich da auch nicht rein. wer sync braucht, muss seine VCOs halt so sortieren, dass es aufs modell passt. möglicherweise vereinfacht die software das dann. du kannst auch nicht von einem VCO 2 andere syncen. nicht direkt. aber bei passender VCO-sortierung sollte das indirekt gehen, also 1->2 und 2->3, wenn die frequenzen sinnvoll verteilt sind, sollte das darauf rauslaufen, dass 1 im prinzip 2 und 3 synced.

den s&h auf prozessor geht vielleicht beim takten, bei der slew auch?

sollte. zumal ein ADC auch nomma nen S&H vorne dran hat, also wirklich den wert zum trigger digitalisiert, und dann isser im speicher. slew von den CV outs ist wie gesagt sehr gut, mein attack kommt ja auf 0.046ms

wie stabil sind denn die vcos eigentlich? braucht es eine autotune-routine?

die muss rein, ja. wobei ich den VCO hier schon stunden laufen hatte, ohne dass er verzogen hat. kritisch ist der CV scaler, zumindest hielt ich ihn bisher für kritisch, scheint aber auch nicht so der fall zu sein. das problem war, einen halbwegs sauberen spannungsgesteuerten widerstand hinzubekommen, um auf nen trimmer zu verzichten. das ding soll kein einziges einstellbauteil in hardware haben. sogar die CVs kalibrieren sich selber also im moment nicht, mit der amplitudenkalibrierung hatte ich noch kleinere schwierigkeiten, aber das krieg ich hin. die nullpunktkalibrierung funktionierte perfekt.

der multiplexer wird ein problem, oder? bei schnellen modquellen..
du hast sicher mehr ahnung dabei als ich.. ich kann mir das aber vorstellen.

du meinst die mod-matrix? nö. die schaltzeiten der analogschalter liegt unter 1usec, und die musst ja nicht dauernd umschalten, die ist quasi im patch festverdrahtet. die modulationsmatrix auch noch zu modulieren halte ich dann doch für etwas bloated. wobei mir die idee eines morph zwischen dreieck und rechteck oder sowas schon gefiel. bräuchte aber pro VCO nomma ne ganze menge VCAs mehr die analogschalter sind so 8er-packs mit serieller schnittstelle, die werden mit 10megabits befüttert, sind also entsprechend schnell umgeschaltet. der controller dafür (vermutlich der gleiche wie für die CVs der VCOs und anhängender VCAs) ist nen 20mhz-typ, der sollte das ordendlich packen. muss aber noch genauer taktzyklen zählen. im moment hab ich noch ordentlich reserven, fahre aber 8bit parallel ohne analogschaltersteuerung.

kleinkram: jo, die anzahl ist fein.. zumal man sich ja noch umentscheiden kann und das ganze noch verdoppeln.. nur: sind die routings dann andere oder quasi so gerorutet, als wärs noch ein mehrstimmen synth..

versteh ich jetzt nicht so ganz, die frage. mehrstimmen isses immer, und das routing ist ja so ein wenig gruppenbezogen. wenn irgendwas mehr gebraucht wird, kommt ne ganze gruppe dran. also in dem fall 8VCO, 8VCF, und der ganze klimbim drumrum.

zum anderen post, den ich bisher übersehen hatte:

die kurve der hüllkurven wäre im prinzip beeinflussbar. ich arbeite bei den LFOs ja eh mit tabellen, intern ists ein einfacher zähler, also quasi "digitaler sägezahn". aus ner tabelle kommt dann z.b. sinus, dreieck und vielleicht auch chaos invertieren und offsets und sonstiger schweinkram auch kein problem. ist ja nur software. da brauch ich nichma C für, das mach ich in assembler. taktzyklensparer.

der VCO haut schon ordentlich genug obertöne raus. allerdings is das delta (titelmusik von nem alten c64-game ziemlich krachüberladen, dass da nix so recht sauber rauskommt. das war auch ein ziemlich chaotisches wellenformumgestecke zwischen den einzelnen tracks. so in "live" kommt da schon ordentlich was raus. ich spiel das ding ja permanent hier bei den experimenten. wenn denn großes interesse besteht, kann ich mal alle wellenformen sampeln und das online stellen. der andere kram, der noch da war, musste vorhin mal weichen, mein quota war wieder mal voll

3 oktaven und 4-8 stimmen ist nicht mehr lange nur traumvorstellung. ich spiel das ding hier zwar im moment noch einstimmig, aber über 9 oktaven. und so referenz mit nem anderen synth isser zumindest innerhalb von den üblichen 5 oktaven auch ausreichend aufm ton. wenn mans noch präziser braucht, kann man auch den scaler in einem bestimmten tonbereich autotunen. halte ich aber nicht mehr für notwendig, nach nochmaliger feinanpassung der franco-kompensation und verbesserung der scaler-schaltung taucht das jetzt schon. hab genug messreihen ins openoffice gezogen und ausgewertet

zum noise muss ich noch schauen, was ich da hinter den filtern so rauskrieg. übrigens auch ein grund, weshalb ich die stufen einzeln abgreifen will. feste 24dB sind da zu hart für nen gscheiten pink noise, ich glaub, 3dB wäre eigentlich das richtige.
was analog realisierbar ist, kommt rein, restlicher dreck kommt von der CPU aber über die hardware an der stelle mach ich mir gedanken, wenn ich meine VCOs, VCFs und VCAs aufm brett hab, und mir die hände reib und die bis dahin vermutlich 200 seiten in diesem thread nochmal durchlese, um zu wissen, was ich noch für komponenten zammlöten muss.

zu den slew rates: ich rechne nur in schnellste. weil das ist hardware. langsam ist dann software. mit den 0.046ms, auf denen ich momentan im idealfall bin, kann ich dann getrost auch mit ausreichend dickem zähler den attack von mir aus 30 minuten lang machen.

lass mal hochrechnen, wie das aussieht, wenn ich den 8bit counter als prescaler bei 20MHz CPU-takt nehme:

sind etwa 75khz aktualisierungsfrequenz für die LFOs und EGs. hm. voll der bloat. so schnell sind die CV-scanner nicht. also 8er prescaler davor.

9,4KHz. immer noch bloat. 64er prescaler.

1179 Hz. das wäre dann etwas schneller als 1ms an auflösung für die aktualisierung. schneller als der CV-scanner, aber kann man mit arbeiten. das würde bedeuten:

attack auf max speed -> wird nicht vom EG direkt gehandelt, der wert wird einfach "sofort" gesetzt.

max speed - 1 würde in dem fall nicht ganz 1ms bedeuten. so. ausgehend von 16bit-counter wären wir da bei 0.0179Hz, das sind 55 Sekunden.

klingt doch mal gar nicht so schlecht. und mit 64er prescaler hab ich dann locker 16000 taktzyklen, um den krempel upzudaten. wenn ich schlampig programmier, werdens 200 pro EG/LFO, bei 32 pro typ wärens dann 6400 taktzyklen.

so. und was macht die CPU in der restlichen zeit? das bissl daten über den TWI schieben frisst jetzt nicht so massiv viel

aber okay. wichtig an der rechnung ist dann die tatsache, wie "digital" das klingt. es sind halt keine analogen EGs und LFOs. da muss ich schauen, dass da keine digitalen artefakte hörbar sind, bei höheren geschwindigkeiten könnten die nämlich spürbar werden, weil ja viele zwischenwerte übersprungen werden.

so. gnug gelabert. mal ne ecke pennen, die woche über wird eh nicht viel passieren.

 

[MiK]

Ich bin bis jetzt immer von 16 OSCs = 8 stimmig bzw. 2OSCs pro Stimme ausgegangen.

vergiss statische konfigurationen. die will ich ja gerade damit abschaffen.
quasi eine schrankwand voll modularsynths. stecks zusammen, wie dus brauchst. nur halt alles in ner rackbox mit midi. und mahagonifront und chromgriffen war nur mal so ne idee. ich hätte ja gerne nixie-röhren und blaue LEDs dazu.

 

[MiK]

hatte heute morgen im stau, inspiriert von jarre, ne idee. ihr wolltet doch wissen, wie die EGs aussehen:

ich nenne die EPs, envelope processors. weil sie quasi wie eine CPU arbeiten. technisch:

ein son envelope ist quasi ein "programm". bestehend aus kommandos und operatoren. da gibts z.b. kommandos wie:

- set
- slew
- wait
- loop

set setzt den angegebenen wert direkt (auf den EP-ausgang, der irgendwo dran hängt)

slew nimmt 2 werte, eine geschwindigkeit und einen wert, und bewegt sich in der geschwindigkeit in richtung des wertes

wait verharrt unendlich lange in einer endlosschleife

loop loopt unendlich lange an die angegebene stelle im "programm".

dazu gibs dann noch ne information, wo im programm hingesprungen soll, wenn das gate weg kommt. das braucht man, um die endloskommandos wait und loop zu beenden.

ausserdem kann jeder wert (sowohl rate als auch der wert, der am ausgang nach vollendung des steps erscheinen soll) nicht nur statisch sein, sondern auch ein "register", was in dem fall als quelle auf einen LFO oder anderen EP zeigt. damit ist das ding ziemlich modulierbar.

und ich muss mir noch gedanken drüber machen, wie ich sinnvoll lookup-tables mit einbinde, um einfluss auf die kurven zu haben, ohne wertesprünge einzubauen. aber immerhin - grobkonzept.

da ich vom user nicht erwarte, dass er eine assemblerähnliche programmiersprache erlernt, um seine hüllkurven zu gestalten, gibts auch da wieder templates, die im expert mode verwaltet und im user mode benutzt werden können.

ach ja, und nochwas ganz anderes. bevor die frage auftaucht:

externe inputs gibts auch. 4 stück vermutlich. hängen an der gleichen stelle wie die VCOs in der schaltmatrix, können also wie noise "neben" nem VCO ton einwerfen, außerdem kann man sie als mod-source benutzen. im zweifelsfall auch hinterm filter, da fast gleichberechtigt wie VCO.

man kann also jetzt seine oszillatoren mit seiner lieblings-CD modulieren

 

[MiK]

sodele. auch wenn ich heut zu faul bin, irgendwas sinnvolles zu entwickeln, so konnte ich doch auf dem weg vom sofa zum kühlschrank nicht am bastelplatz vorbei, ohne mal bissl zu spielen

da das im delta-testsound nich richtig gscheit rüberkam, hier mal en detail. das ist jetzt einzig und alleine ein VCO, die hüllkurve beschränkt sich auf "D", also attack is quasi max, und auf sustain und release hab ich gleich ganz verzichtet, war nur ein test (bei delta gibs ja noch nichma ne hüllkurve oder nen VCA).

also hier, verschiede wellenformen in verschiedenen frequenzen, mit dem VCO und natürlich VCA dahinter, daß die hüllkurve auch wo ankommt. an "modulationen" war nur das alte finger-interface vorhanden, pitchbender und ein knobb am BCR2000 für die pulsweite, wo benutzbar.

"guess waveforms". sägezahn, rechteck, dreieck, sinus, alles dabei, teilweise mit subosc 1 oktave tiefer, und da es "mal gschwind" ist, übersteuerts stellenweise (wenn der subosc mit dran hängt), außerdem ists musikalisch völlig wertfrei. aufgenommen mit audacity über den mac line in, pausen rausgeschnitten, mp3 encoding mit itunes 224kbit VBR max quality, ich hoffe, dass diesmal nicht zuviele oberwellen fehlen. aber das WAV is mir echt zu breit zum hochladen

bastelplatz totale: http://k5000.org/pix/IMG_3208.JPG
bastelplatz, nur der "breadboard-synth": http://k5000.org/pix/IMG_3209.JPG

 

[Moogulator]

ich poste mal das von drüben, weil sehr interessant:

aussm ek forum:

hmm, bedeutet das multistage hüllkurven?
jau, also 12 sind sehr fein.. 8 sind auch schon sehr ordentlich!! sehr!!

nö. nix multistage. das ist ne ecke mehr mal kurz zusammengefasst:

das ding wird in ner art programmiersprache programmiert, die man so darstellen könnte:

start: set(rels, 32767)
slew(rels, ctime, val(200), val(16384))
loop(rels)
rels: slew(rels, ctime, val(200), val(0)
jump(start)

mehr als die 4 kommandos gibts auch nicht. bedeutet:

set - setzt den ausgang auf den wert 32767 (was maximum ist, denn das ganze ist bipolar , und während dieses kommando aktiv ist, wird bei einem gate change das label "rels" angesprungen

slew - wieder das "rels", was bei einem gate change angesprungen wird, also abbruch des slew kommandos und sprung dahin. slew fährt vom aktuellen wert des ausgangs mit constanter zeit, die in val(200) ausgedrückt wird, zum wert 16384.

loop - so. hier bleiben wir jetzt mal. bis das gate sich ändert, dann gehts zu rels

das nächste slew ist gleich wie das obere

jump - springe zum label "start".

das ganze ist eine normale ADSR in diesem falle. und ein sprung zu "start" ist einfach eine endebedingung, hier ist also der EP fertig mit der arbeit, weil ein sprung zum start keinen echten sinn macht, und sollte man den doch mal brauchen, fügt man irgendein anderes kommando ein (was auch ein jump sein kann), um das label "start" mit nem dummy zu füllen, und in der sinnvollen variante, aus "start" zu springen, eben das kommando hinter dem jump an "start" ausführt. uff. blöd erklärt. ich weiss

auf jeden fall kann das ding durch das jump-kommando loopen, es kann den slew mit konstanter zeit oder mit konstanter geschwindigkeit durchziehen (klingt ja so, als wär das im prinzip beides das gleiche, aber sowohl der zeit/geschwindigkeitswert als auch das slew/set-ziel können auch register sein, also z.b. ein LFO oder ein anderer EP. ausserdem ist in jedem kommando eine adresse angegeben, wohin bei gate change (also quasi release) gesprungen wird, damit kann ich sogar während des EP-laufs nochmal das verhalten bei release ändern.

und wenn man nen scheiss zusammenprogrammiert hat und die hüllkurven nicht aufhören für eine voice, dann schlägt halt irgendwann die garbage collection zu und räumt die voice weg, wenn sie für neue töne die resourcen braucht.

also ich weiss nicht, wie du das siehst, aber ich find das konzept geil

auf spezielle kurven verzichte ich da jetzt aber doch, die kann man in gewissen grenzen mit mehreren slews abbilden, oder auch modulationen benutzen, das problem ist, wenn ich mit kurven arbeite, ist das ein mords theater, da die synchronisation der ausgangswerte aufrecht zu erhalten. weil eine kurve für den ganzen EP halte ich auch für doof. das aber wiederum wäre da kein problem. vielleicht bau ich zu EPs und LFOs noch "modulationsadapter" rein, mit denen man die ausgangswerte auf andere ausgangswerte mappen kann. der oberheim matrix hat doch da auch sowas drin. das wär kein problem.

und keine sorge. der user muss nicht assembler lernen. es gibt wieder templates für die gängigsten bauarten, wo er quasi nur noch seine zahlen eintragen muss. selbstverständlich darf er trotzdem auch dann modulationsquellen benutzen.

und zur größe: es stehen 64 bytes zur verfügung für so ein "hüllkurvenprogramm". ergibt sich dadurch, dass das kommandobyte in 2 bits das kommando und in den restlichen 6 bits die adresse kodiert. und um nicht die ganze tabelle bei jump oder gate change scannen zu müssen, ist es nicht die kommandonummer, sondern wirklich die adresse. zum "platzverbrauch":

loop und jump brauchen nur das kommandobyte
set braucht kommandobyte und 2 bytes für den wert
slew braucht kommandobyte und 4 bytes für 2 werte

in den werten werden dann die untersten 1-2 bits wieder für was anderes benutzt, bei der zeit z.b. für die umschaltung constant time/speed und vor allem für die umschaltung, ob es ein direkter wert sein soll oder ein registerwert rangezogen soll von woanders. bei dem wert, auf den gesetzt werden soll, entfällt das time/speed bit, also nur das register/direkt bit ist da dran.

bei 0.8192ms scan rate von dem ding bedeutet das dann bei constant time zeiten von 3,2786ms bis 53,683s für so ne stufe. wer den schnellen attack braucht, macht nen set. 1.5ms geht entsprechend nicht, die mindestauflösung ist 3.2768ms. ne alternative wäre noch ein bit zu opfern und da ne umschaltung reinzumachen, ob das ding mal 1 oder mal 8 (wegen den geopferten bits) gilt. dann kannst im schnellen bereich in 0.8192ms-auflösung handtieren und im langsamen bis zu fast ner minute.

boah. ich schreib zuviel. echt mal. aber ich hoffe, es kommt durch, was das ding kann, und ich hoffe, du bist einverstanden mit der funktionalität

...oberheim: das sind "slow mods" also keine VCOS als quellen, es sind normale modmatritzen.. ist was anderes..

eben. alles, was die CPU generiert. das ist das, was bei mir mit LFOs und EPs ja auch passiert. sieht nur nach viel aus beim oberheim, weil man noch massig midi-controls und so zeug da mit reinnehmen kann. aber kein einziger echter analoger dabei.

das routing soll analog sein? das ist ja ansich gut, dh die LFOs und co kommen dann via DA in das routingsystem und werden dann analog verknüpft?

indirekt. die software-LFOs sind digital geroutet. die werden intern auf die entsprechenden CVs aufgerechnet. analog wird z.b. der kram zwischen den VCOs, der kram zwischen VCOs und VCFs geroutet, der kram zwischen allen analogen komponenten eigentlich.

mp3: ja, aber das klang noch nicht soooo breit..
da geht sicher noch mehr..

das is nur _EIN_ VCO. und wenn dus in ganz exakt haben willst, schick ich dir gern was WAV dazu

aber dazu gesagt: das ist mir dem line in des mac aufgenommen, ich will ja nich wissen, was der da alles wieder klaut. hier fehlts im moment nur noch an vernünftigem recording-kram. firewire-audio kommt erst gegen monatsende her. die sändigen reichelt-bestellungen blockieren momentan mein budget in der richtung etwas.

was auch ginge ist karplus strong.. sprich: impulse und kammfilter etc.. sehr cool..

muss ich mich mal reinlesen, was da alles so geht. das mit dem chaos hatten wir ja schon mal im anderen thread.

EP? env processor, oder?

jup

gitbs eigentlich einen namen für das monsterlein™?

momentan bin ich aufm trend, den ganz schlicht "MiK-one" zu nennen. das könnte aber auch sein, daß die 4VCO handlöt-edition so heisst, und wenns alles mal aufn markt kommt, dann eben auch diese edition existiert. wie evolver und poly evolver quasi. dann gibs vielleicht nen MiK-two mit 8 VCOs und nen MiK-four mit den 16 VCOs. und allem was dranhängt, siehe anderer thread für gruppenbeschreibung.

man könnte natürlich auch digitale wellenformen so bauen, aber das bringt natürlich nicht sooo viel.. aber als gimmick ginge es..

nachdem es heute mal wieder etwas lauter im büro war, habe ich mir gedanken gemacht, wie ich durch geschickte nutzung der modulierung des VCF-cutoff per s&h mit meinem EP und etwas noise und bissl anderen zutaten ne hilti nachbilden kann

also da werden schon seltsame sachen rusfallen können am ende. und wavetables wirds möglicherweise auch irgendwo geben. für den LFO ja eh schon geplant, weil ich keinen sinus online rechne. da kommt nen viertelsinus als tabelle ins rom, und die anderen 3 viertel werden daraus gerechnet. sägezahn und dreieck zusammenrechnen is ja noch handlich in assembler.

wie weit diese samples aber dann userbearbeitbar sind, und was für nen umfang das hat, weiss ich noch nicht. der sinus wird fett hochauflösend (drum auch nur nen viertel, sind nämlich 32 kilobytes damit, also 16384 werte in 16bit)

 

[Moogulator]

so, ich glaub das ist zwit für ein schönes blogcontent

vcos klingen besser mit diesem neuen demo.. hab ich drüben im EK noch nicht gehört gehabt..

evtl hast du ja zeit ,mal eine kleine sektion auf deiner site zu dem teil zu machen..? auch für die englisch sprechenden..

 

[MiK]

so, ich glaub das ist zwit für ein schönes blogcontent

ohja. das mit beiden threads is brutal suboptimal. ich sollte mir mal angewöhnen, den krempel anderweitig zu dokumentieren und im forum nur noch nen URL als antwort zu posten, das ist dann transportabler

vcos klingen besser mit diesem neuen demo.. hab ich drüben im EK noch nicht gehört gehabt..

ah. okay. ich dachte, du meintest da schon den dirty hack von gestern abend. also hier direkt ausm VCO rausfallend ueber bissl mixkram auf die A500 und die dicken boxen drückt das schon recht angenehm

da sind auch einige störungen weniger drin, die ich schlicht auf kompressionsartefakte schliesse. ich würd ja das WAV hochladen, aber auf meinem webspace ist mal wieder ende quota, und ich bin zu geizig und zu faul, da mal irgendwo bei nem billighoster nen gig zu holen, und der heimserver hat zwar 1,2TB storage, dafür aber nur 128kbit.

aber ich kanns gern zur verfügung stellen zum woanders ablegen. sind semihandliche 19MB. aber wie gesagt - line in vom powermac g4. mein recording-equipment ist eher eingeschränkt im moment. könnts höchstens in den S2000 pumpen.

 

[Moogulator]

hosting: och ,das ist gut.. so wird das ding nur langsamer, nie überlastet..
ist eher gut.. manchmal wäre mir das auch lieber.. aber zzt ist da genug trafficreserve..

19MB sind ok.. das ist garnichts - heute..
wenns nicht anders geht, kann ich die auch solang hosten..

das neue demo ist eh besser als das alte..

threads.. ok, dann lassen wirs hier, weil das schon so viel antwort gab..

 

[MiK]

19MB sind ok.. das ist garnicht heute..
wenns nicht anders geht, kann ich die auch solang hosten..

44100 16bit mono. is ja nich lang.

aber wart. heut abend oder morgen gibs dann noch die EPs mit zu belauschen. das rentiert dann evtl. eher.

werd nachher dann mal ne weile neue posts ignorieren, sonst wird das nix mit coden, weil ich wieder permanent am posten bin

 

[Moogulator]

naja, ich finds super,das du so viel erzählst..
du kannst natürlich auch kürzer schreiben.. je nach zeit..

aber ich denke, das interessiert viele, wie so ein teil "entsteht".. erinntert dann ein bisschen an die rozzbox entstehungsphase.. die auch recht öffentlich war, jedoch nicht so detailreich..

 

[MiK]

jo, mir hilft das geschreibsel ja auch irgendwo. da sortier ich immer meine noch nicht ganz definierten gedankengänge zu irgendwas zu einem benutzbaren gesamtbild

übrigens programmänderung im bereich EP/LFO:

es wird keine LFOs geben. sowas wird völlig überbewertet

hintergrund ist, dass meine EPs die funktionalität eines LFO ganz problemlos übernehmen können (dreieck, sägezahn, reckteck sind ja quasi als loop programmierbar). und so brauch ich nur eine schnittstelle für beides. entsprechend kann man den trigger eines envelopes auf alles mögliche an zeug legen. neben default note-on halt auch weg davon (freilaufender LFO) oder midi sync in diversen formen (ist zumindest für LFOs brauchbar, könnte für envelopes aber auch sehr interessant sein).

neu hinzugekommen (bzw. altes produkt mit neuem namen ist dann noch ein delay. ist eher simpel. ist ein slew mit constant time auf ein register. das register ist der eigene ausgangswert

ich überlege noch, wie ich da "chaos" reinbringe. eventuell benutze ich doch den ADC vom prozessor und häng ein paar quellen dran, die interessant zur modulation der EPs (und damit auch LFOs) sein könnten. vielleicht macht das aber auch die haupt-CPU und schickt solche daten der EP-cpu. zumindest ein wenig randomness, also noise, wäre sicherlich nicht uninteressant. ist auch sinnvoll, wenn man mal im Sequencer etwas zu gründlich mit dem quantisieren war, dann kann man den startdelay seiner envelopes etwas mit random modulieren, und schon isses wieder lebendig

habs übrigens gestern nimmer ganz geschafft, den EP fertig zu coden. zu müd, haufen blöde bugs zusammenprogrammiert. vielleicht heute.

 

[Anonymous]

es wird keine LFOs geben. sowas wird völlig überbewertet

Meinste von der internen Logik her oder von der Bedienung?

Ein "LFO" den man als "LFO" benutzen will ist jedenfalls schneller bedienbar
als ein "EP", den man als "LFO" benutzt.

Wollte ich nur mal zu bedenken geben.

 

[MiK]

Meinste von der internen Logik her oder von der Bedienung?

von der internen logik her. durch die templates gibts für den user ein template, was man dann wie nen normalen LFO einstellt. ob der dann unter den envelopes erscheint, oder ob ich ins templating den "einsatzzweck" mit einbaue und den dann nicht in ner envelope-gruppe, sondern in ner lfo-gruppe erscheinen lasse, hab ich noch nicht im detail durchgeplant. das kommt dann mit dem userinterface. aber es wird vermutlich einfach 4 templates für LFOs geben:

LFO triangle
LFO ramp up
LFO ramp down
LFO square

und man kann überall noch "übersetzungstabellen" anflanschen, primär mal "sinus". also kann man entweder aus dem triangle ider dem ramp up dann auch nen sinus bauen. möglicherweise im template, je nachdem, wo ich den tabellenparameter mit reinpacke. dann gibts halt noch nen "LFO sine"

Ein "LFO" den man als "LFO" benutzen will ist jedenfalls schneller bedienbar
als ein "EP", den man als "LFO" benutzt.

ein EP ist für einen "user" eh unbenutzbar. den muss man nämlich recht sorgfältig programmieren. drum gibts ja für alle komplizierten sachen an dem ding templates, die man im "user mode" einfach benutzen kann und im "expert mode" verwalten kann, mit vollem zugriff auf alle möglichkeiten. das gesamtkonzept ist für nen normalen patchschrauber, vor allem, wenn er noch nie mit nem modularen gearbeitet hat, schlichtweg zu komplex. aber auch der normale user wird sich im laufe der zeit vermutlich mal mit dem expert mode befassen und da stück für stück reinkommen und tolle sachen machen können. die kiste ist ja nicht per definition als presetschleuder ausgelegt

Wollte ich nur mal zu bedenken geben.

useability ist da schon lang eingeplant. wenn ich voraussetze, daß man erstmal ne 1000-seiten-anleitung lesen muss, um nen sound zu editieren, wird das ding etwa so sinnvoll werden wie ein K5000 ohne sounddiver.

 

[Anonymous]

Hört sich gut an.

 

[MiK]

so. jetzt gibts eins auf die ohren

konstruktion: 1 VCO, 1 VCA, 4 EPs (envelope processors)

programmierung der EPs:

ep0:    ep_glide(6, ep_value(32767), ep_consttime(1024))        ; 0
        ep_loop(6)                                              ; 5
        ep_glide(6, ep_value(-32768), ep_consttime(8192))       ; 6     release
        ep_jump(0)                                              ; 11

ep1:    ep_set(19, 0)                                           ; 0
        ep_glide(19, ep_value(0), ep_consttime(1024))           ; 3
        ep_glide(19, ep_regval(2), ep_consttime(64))            ; 8
        ep_glide(19, ep_regnegval(2), ep_consttime(64))         ; 13
        ep_jump(8)                                              ; 18
        ep_glide(19, ep_value(-32768), ep_regconstrate(2))      ; 19    release
        ep_set(24, ep_value(32767))                             ; 24
        ep_jump(19)                                             ; 27
        
ep2:    ep_set(19, 0)                                           ; 0
        ep_glide(19, ep_value(0), ep_consttime(2048))           ; 3
        ep_glide(19, ep_value(32767), ep_consttime(65535))      ; 8
        ep_glide(19, ep_value(0), ep_consttime(65535))          ; 13
        ep_jump(8)                                              ; 18
        ep_set(19, 1024)                                        ; 19    release
        ep_glide(22, ep_value(0), ep_consttime(4096))           ; 22
        ep_jump(0)                                              ; 27

ep3:    ep_set(14, 0)                                           ; 0
        ep_glide(14, ep_value(20000), ep_consttime(800))        ; 3
        ep_glide(14, ep_value(-20000), ep_consttime(800))       ; 8
        ep_jump(3)                                              ; 13
        ep_glide(14, ep_value(20000), ep_consttime(50))         ; 14    release
        ep_glide(19, ep_value(-20000), ep_consttime(50))        ; 19
        ep_jump(14)                                             ; 23

das sind die 4 Programme. ep0 bis ep3, die ich da jetzt zum testen genommen habe. ich erläuter das jetzt nicht weiter, es ist halbwegs selbsterklärend, wo "value" steht, ist ein direkter wert angegeben, "regval" ist ein wert aus einem anderen register (im moment ist das einfach ein anderer EP), consttime ist konstante zeit für den glide, constrate konstante geschwindigkeit. ist jetzt mal ziemlich krank programmiert, verhält sich auch glaub noch etwas seltsam, evtl. muss ich da noch debuggen, aber ich muss den code eh noch optimieren. außerdem habe ich schwierigkeiten, die tragweite meiner konstruktion zu überblicken

Modulieren tun da:

EP0 -> VCA
EP1 -> pitch
EP3 -> pulsweite

EP2 moduliert nix, aber der wird z.b. von EP1 benutzt.

klingen tut das so:

da ist nix gefaded oder sonst wie mit effektgerät versehen, ganz exakt das, was da zu hören ist, fällt hinterm VCA raus. der VCO spuckt übrigens auch ausschliesslich rechteck auf den VCA, keine anderen wellenformen oder gar subosc.

wie man zwischendrin mal hört, kann man anfangen, mehrere noten zu spielen, und es fadet rein. das liegt daran, dass der EP für den VCA so konfiguriert ist, dass zuerst ein glide kommt. es wird also kein startwert genommen. er wird schon sauber retriggered, aber er hat kein bedürfnis, vorher auf 0 zu gehen, weil es ihm nicht gesagt wurde

nuja. ich finds ganz witzig. es klingt für den aussenstehenden schrecklich, für den modularfan vermutlich durchaus interessant.

einsatzzweck eines EP:

- hüllkurvengenerator
- LFO
- sample&hold
- Sequencer
- arpeggiator

mehr nützliche einsatzzwecke hab ich noch nicht gefunden. is aber insgesamt mehr als ADSR

Edit: nicht sägezahn, sondern rechteck kommt ausm VCO auf den VCA. klar. wegen pulsweite

 

[Moogulator]

sind die schnellen mods lfo bedingt? nehme ja mal an ,ja.. oder?

 

[MiK]

sind die schnellen mods lfo bedingt? nehme ja mal an ,ja.. oder?

wie meinst das jetzt? in dem konstrukt gibs nur 1 VCO, 1 VCA und die 4 EPs, wovon EP2 in der gate-on-phase quasi ein modulierter LFO ist, wie auch EP4, der die pulsweite moduliert.

updatefrequenz der EPs ist etwa 1ms, entsprechend definiert das die maximalfrequenz, wenn man sie als LFO benutzt, rechteck 1khz . bei sägezahn/dreieck theoretisch auch, nur ists bei 1khz dann halt ein rechteck, weils keine zwischenwerte mehr gibt durch die updatefrequenz.

diese wird übrigens eventuell noch etwas schneller, weil mein grundplan, 64 von den dingern in eine CPU zu klatschen, nicht ganz aufgeht (performance und ram fehlen da), vermutlich bin ich schwein und mach 8 pro CPU, jedes VCO-doppel kriegt seine eigene CPU. kost ja nix und dann hab ich schon allein für die envelopes/lfos/whatever EP-funktionen 8 CPUs im synth... klingt wichtig, sowas!

 

[Moogulator]

alles klar, frage beantwortet fein!! der lfo ist ein schneller modulationsoszillator, da er nicht mehr "low" ist .. schön!!!