Thomasch

Geht die Folge heute noch online? Bis jetzt gibts nur die CC2 Folge vom 19.04. unter "Aktuelle Sendung" zu sehn.

Hallo Rolf, wie ich im CC2 Forum lesen konnte, bist du gerade auf der Suche nach einer schnelleren Hardwareplattform für den potentiellen Nachfolger des DegenErator. Hast du schon Vorstellungen in welche Richtung der neue Synth gehen soll?

Hi Sauraen, I like your Idea to develop a V2.0! Here are my thoughts about a potential V2.0: 1. Velocity Velocity mapping is meager with MBFM V1.4 - actual only one free assignable target and the 3stage velocity to global-volume chooser is possible... Thats far to less routing possibilities to make really living and breathing velocity sensitive sounds. Would be really cool to use velocity messages to modulate multiple parameters on independend modulation depths. When talking of modulation depth, i think of a low and a hi value. (With V1.4 it's a little different it uses instead of a hi value a range value.) with firmware V1.4 the base value of the velocity modulated target parameter is simply replaced by the velocity value you feed into. It woul'd be much better if velocitymodulation would not replace, but rescale the actual value of its target. 2. Filtersection a polyphonic Filter woul'd be great... 3. ext. LFOs, Envelopes LFOs should be switchable monophonic/polyphonic. much more external Envelopes - at least 1 per operator, to override the internal Envelopes and get rid of the 16step value limitation. maybe a flag to switch between internal and external envelopes woul'd make sense. 4. User Interface I'd vote for a full 4 OP Encoder Setup, to minimise stupid display page hopping. Even the use of LED-Rings would ease the use. You coul'd recognise the whole setting of a soundpatch with just one look. Using of OLED Displays woul'd also be a big benefit for readability from side angle views. Unfortunately some sizes and colors (2x40) of Character OLEDs are hard to get, graphic OLEDs are more easy to get. I woul'd prefer big Graphic OLEDs because things like algorithmstrucures, waveformpictures, slider, rotaries and even graphical elements to hilight and group Parameter. Different fonts and font sizes will also be possible. 5. V 2.0 and DAWs MBFM V 1.4 reacts a little critical in case of program- and bankchange messages recieved from DAWs. simultanious programchanges on more than 1 channel doesn't work. this blackout like behavior has to be adressed with the new V2.0 MBFM V1.4 use programchange messages and bankchange LSB Messages on CC#0. Unfortunately Abeton bangs always Prog.change together with Bankchange LSB on CC#0 and additionally a Bankchange MSB on CC#32. Please keep this in mind, and keep CC#32 reserved when you attach parameter to CCs. Best regards Thomasch

Hallo Thorsten, hast du zufällig einen Link auf die Sourceforge Seite? Ich finde nämlich nix über Google. 1. Der CC Editor für den Drum Part ist übrigens sogut wie in trockenen Tüchern. Siehe Screenshot: Das Device funktioniert schonmal prima, ich werd aber noch ein paar Optimierungen und Verbesserungen vornehmen. Dazu gehört auch eine lokale SoundLibrary, die unabhängig von den Hardware Presets läuft. Als nächstes werde ich mir eine CC Version für die 4 Voice Parts Vorknöpfen. Wenn alles was mit CCs machbar ist abgearbeitet ist, werd ich mich um die SysEx Sachen kümmern. 2. Zu den SysEx Spielereien: Einfache SysEx Befehle die einem spezifischen UI Objekt im Editor zugeordnet sind, kann ich schon versenden. Möglich sind auch Dumps von beliebig langen SysEx Messages. Einzige Einschränkung, ich kann in dem SysEx Dump bisher leider nur eine begrenzte Anzahl von Variablen setzen. Zumindest mit dem Objekt, daß ich momentan verwende. Aber das ist nur ne Frage der Zeit, bis ich da nen Weg finde. und bis dahin sendet halt jeder Parameter ne komplette SysEx Message für sich allein. Ich bin halt noch kompletter Anfänger, was die visuelle Programmiersprache Max angeht und mit anderen Programmiersprachen hab ich keine Erfahrung. (wenn man von ein paar "if then else" Schleifen in simplen BASIC Programmen irgendwann in den 80er Jahren absieht.) Max hat über 1000 unterschiedliche Objekte und ich kenne bisher nur einen Bruchteil davon. Da muß ich mich erstmal zurechtfinden. Nunja, der Winter wird eh wieder lang... :smile: 3. Beim Entwickeln des Drum Editors hab ich mich mal versucht in das interne Routing der einzelnen Instrumente hineinzudenken. Ganz ehrlich - ich blick nicht so richtig, welcher Parameter mit welchem da intermoduliert. Es macht mich total irre, daß ich nicht durchblicke wie die Parameter miteinander interagieren und das tun sie ja. Dreh ich am Multiplier des Cymbals, ändert sich die Hihat. Dreh ich am Frequeny und Frequency Increment Regler des Cymbal/Tom ändert sich ebenfalls die HiHat... Die Snare spuckt bei manchen Waveformen völlig unvorhersehbar unterschiedliche Tonhöhen aus. Dabei scheint es wiederum eine Abhängigkeit zu geben, ob gleichzeitig das Cymbal zur Snare gespielt wird. Bei der Bassdrum hab ich den Eindruck, daß der AM Modus nichts weiter macht, als den Modulator auszuschalten. Ich blick nicht durch. Gibts es irgendwelche Blockdiagramme oder Dokumentationen, wie der Drumpart intern verschaltet ist? Ich würde gern die Routing Struktur, den Algorithmus der hinter dem User Interface steckt verstehen. Wenn man weiß, was passiert, macht es das Soundschrauben nämlich unendlich leichter. 4. Ein weiteres Max4Live Projekt, daß bei mir aufm Plan steht, ist ein Pattern basierter Arpeggiator. Um es kurz zu machen, jedem gespielten "Finger" wird dabei ein eigener Step Sequencer zugewiesen. Daß heißt, greife ich bspw C-Dur dann wird nach Tonhöhe sortiert und indexiert. C, E und G wird jeweils ein Stepsequencer zugeordnet, der die Pitch Werte um die passenden NoteOn- und NoteOff-Velocity Werte des ArpPatterns ergänzt. Grundvoraussetzung für ein solches Device wäre erstmal ein Patch, der mir die einzelnen Noten eines gespielten Akkords zur weiteren Verwendung auf einzelne Outputs separiert. Wenn dann die einzelnen StepSequencer Linien noch hübsch in einer Matrix (ähnlich einem Piano Rol)l angeordnet werden, dann läßt sich damit ne hübsche Begleitautomatik erstellen, die zudem mehrstimmig erklingen kann, was weit über die Möglichkeiten eines normalen Apeggiators hinaus geht. Worauf ich hinaus will... ...mit einem Max Patch, bei dem ich die einzelnen Stimmen eines Akkords den (auf jeweils einen eigenen Audioausgang gerouteten) 4 MBFM-Voices dynamisch zuordnen kann, ist es problemlos möglich 4 stimmig polyphone Spielereien mit externen Filtern zu veranstalten. Das schreit geradzu nach einer Verwendung mit der MBFM. Und wem 4 Stimmig polyphone Filter nicht genug sind, der kann damit auch mehrere MBFMs damit kaskadieren. Natürlich immer genug Audioeingänge am Interface vorausgesetzt, müßten das ja nichtmal echte Hardwarefilter sein. In Max4Live wär es möglich Filter Devices zu erstellen, die man einfach in jeden Einganskanal legt und die über die MIDI Signale mit getriggert werden. Doch das sind alles erstmal noch Luftschlösser, die ich frühestens bauen kann, wenn ich bei Max ein wenig mehr durchgestiegen bin. Aber alles halt Schritt für Schritt. In diesem Sinne Gruß Thomasch P.S. @ Thorsten Zu 4. So ein Pattern basierter Arp wär doch sicher auch eine feine Sache ganz in MIDIbox Hardware und mit einer Button Matrix. Das wär der absolute Bringer, wenn du sowas direkt für die MIDIbox proggen könntest. Der Winter wird schließlich lang - aber ich glaube, das sagte ich schon. <grins> Mit ner schicken 16x32 Button Matrix dürfte das ein ziemlich heftiges und vor allem Liveauftritt taugliches Tool werden, mit dem selbst ungeübte Keyboardspieler klasse Ergebnisse erzielen könnten. Wäre eigentlich ein eigenes Thema wert, aber ich fürchte deine ToDo Liste ist sicher übervoll. ;) P.P.S. Ich werde so schnell wie möglich eine erste Version des Device bei maxforlive.com hochladen, muß aber den Patch noch ein wenig ausputzen vorher. Den Downloadlink poste ich dann hier.

Hallo Rolf, bitte berichtige mich, wenn ich falsch liege. Dein Synth ist polyphon spielbar. Dein Synth hat monophone Filter. Merkst du worauf ich hinaus will? Freilich der Vorzug von echten analogen Filtern gegenüber optimierten µC Algorithmen ist nicht von der Hand zu weisen, aber wenn dein Synth auch in Sachen polyphoner Spielbarkeit Sinn machen soll, hast du nur 2 Optionen. Option 1: Analog Filter als Goodie für monophones Spiel vorbehalten und alternative Digitalfilter direkt im Code des µC für die polyphon gespielten Sounds. Vorteil hiebei wäre, daß du die Filtermodelle so einfach wechseln könntest, wie deine Socken. <lach> Das geht bei ner Hardwarelösung natürlich nicht so einfach, bzw gar nicht, die komplette Charakteristik des Filters auf einen Schlag zu ändern. Option 2: Du erweiterst die Kiste um weitere Audio Ausgänge und progammierst dazu eine einfache Stimmzuordnung. Der Hardware Aufwand für zusätzliche FIltermodule steigt dabei allerdings beträchtlich. Aber nuja - von nüx, kümmt nüx... Die Anzahl der Ausgänge richtet sich dann danach, wieviel Stimmen gleichzeitig spielbar (und vor allem filterbar) sein sollen. Was sagst du dazu? Liebe Grüße Thomasch <EDIT> Der Winter wird lang, darum noch mehr Vorschläge: Es gibt natürlich noch Option 3 Das wäre dann eine Kombination aus Option 1 und Option 2. Ist dein Synth eigentlich auch multitimbral ? Auf Deutsch: kann er Bspw. auf MIDI Kanal 1 Preset #3 spielen, auf Kanal 2 Preset # 7 und auf Kanal 5 Preset 125 ? Hast du evtl auch mal darüber nachgedacht eine eigene Sektion für Drum Patches zu implementieren? Das macht natürlich nur Sinn, wenn die Kiste auch multi-timbral ist. Ein zusätzlicher Eingang für externes Audio Material wär sicher auch lustig. Die simple Version würde dabei einfach nur die Analogfilter einschließen, es wäre aber auch denkbar, externe Signale als Oscillator erstz zu Verwenden. Wie viel Oszillatoren pro Stimme werden nochmal verwendet? Da kann man doch sicher noch aufstocken. Na wie auch immer, dein Synth sieht ja jetzt schon echt cool aus, aber ich denke du solltest es wirklich auf die Spitze treiben. Im Zweifelsfall mußt du halt nen dickeren µC nehmen. <grins>

Hallo Leute, die kalte Jahreszeit steht vor der Tür und das ist ja bekanntlich die beste Zeit um an diversen Projekten zu Tüfteln. Eines dieser Projekte besteht darin, einen "MIDIbox FM CC & SysEx Editor" für Max for Live zu entwickeln. Ich habe bereits mit der Entwicklung begonnen. Ich werde den Editor auf mehrere Devices aufteilen, so daß man sich immer das jeweils richtige Device in den jeweiligen Kanal legen kann. Es wird Editoren für Voice 1-4, Drumset und für globale Parameter geben. Mit den CC Parametern habe ich bereits begonnen, die Umsetzung sollte relativ schnell gehn. Erste Ergebnisse könnt ihr in den nächsten Tagen erwarten. Etwas schwieriger wird es mit SysEx Parametern, da Ableton Live SysEx Messages nicht unterstützt. Es gibt da aber einen Workaround, dabei sende ich die SysEx Werte über eine IP an ein externes Programm (MIDI-UDP-Bridge). In diesem Programm stell ich mir dann nur den Midi In/Out SystemPort ein und übergehe damit Abletons Limitierung. Hab ich schon mit einem zweiten Editor an dem ich arbeite (für Quasimidi Sirius) getestet und läuft prima. Einziger Nachteil bisher - das Programm hat eine feste IP und so ist ein paralleler Betrieb für beide Editoren nicht möglich, weil die ja über verschiedene Ports senden müssten. Mal schauen, ob sich da ne Lösung findet. Um eine modifizierte MIDI-UDP-Bridge selbst zu entwickeln bräuchte ich nicht Max for Live, sondern die Stand-alone Version Max/MSP/Jitter von Cycling74. Aber vielleicht findet sich auch über die einschlägigen Foren jemand, der mir ne modifizierte Version zusammenhackt. Erste Frage ( @ T.K.): Gibt es auch eine SysEx Dokumentation für die Wavetable Adressen? Das wär nämlich absolut "Feini-Feini", wenn man das Ding endlich mal in nem Übersichtlichen Sequencer UI editieren könnte... Ich find das Gewurstel auf nem 2x40 Display nämlich ziemlich uninspirierend, da man halt immer nur einen Ausschnitt der Sequenz sieht. Zweite Frage: Wer von euch nutzt Ableton Live mit Max for Live und hätte Interesse an einem solchen Editor? Meldet euch mal mit nem kurzen "Hier", ich brauch dann nämlich Beta Tester. ;) Bis die Tage Thomasch <EDIT> Sollte sich jemand mit der Stand-alone Version von Max/MSP/Jitter finden, der Willens ist mir beim Exportiern zu helfen, so wäre der Editor auch als VST/AU/Stand-alone für Mac & PC zu realisieren. Damit wäre der Editor auch für die Besitzer anderer DAWs verfügbar. Max for Live bietet solche Export Funktionen leider nicht an, die Patches müssten aber kompatibel zu Max/MSP/Jitter sein Als normales VST / AU Plugin wäre das Ganze nämlich auch eine "Ctrlr" Alternative. Bei mir aufm Mac funktioniert Ctrlr nämlich nicht so richtig. Hängt sich ständig auf oder stürzt sogar komplett ab und reißt dann Ableton gleich mit...

@TK. Is it possible, that the MBFM reacts a little unstable, when recieving Program Change Messages on different channels at the same time? I have tested my MBFM Patchselector device with another hardware synth (Quasimidi Sirius), and everything works well. With the MBFM, simultanious Programchanges on more than one channel are not possible. :(

Program Change will not work, because the MIDI mapping in MBFM is not in a straigt General MIDI like CC mapping. The problem is the Bankselect LSB (Sub Bank) Message on CC 32, that Ableton always sends if you select it in "Pgm Change" section of the Clip. Ableton will even send a Bankselect LSB Message on CC 32 if Bankselect MSB (Bank) on CC 0 is set to a Value while the Sub Bank Field is set to "---" I have found 2 simple workarounds to fix this problem. Set "Bank" and "Sub" to "---" and use only the "Pgm" Field. This way you couldn't use Bankselect, but Program Change will work. A better workaround is using Max for Live. I made a little patch to set up Bank and Program Change on my MBFM - the "MBFM Patchselector". Open an empty Max4Live MIDI Device and copy'n'paste the following code into its editor window. The device has controls for Bank and Program. As a bonus, theres an additional dropdown menu that shows GM Programnames, which is usefull if you use a GM Bank with your MBFM. Automate the Bankcontrols of the MBFM Patchselector device in the &quot;Envelope&quot; section of your clip and Program/Bank changing will work fine. This way you can also use multiple sound programs from within one clip (in a serial way). [EDIT] There is one Issue - if you use multiple MBFM Patchselector devices on multiple MIDI Channels - this seems to work only on one MIDI Channel. :( If you start clips on more than one channel at the same time it seems to change the values only on one channel. If you start these clips one after another, everything will work fine.<br /> I dont know, whats the problem, maybe some of you guys will find a solution to fix this. <pre><code> ----------begin_max5_patcher---------- 2540.3oc0ZssaajiD8Y6uBBsujEaRPe+x9lsSbLvrdSPbvLCPvf.pVzRLtUy d6tkujAy+9VrNTsZa43KJVwXdvxMOjMYwhjUcNT5O2cmQiMWpZGI92hOK1Ym +b2c1ggr.63Juyn4xKKJksbyFUXlOWU0M5kntN0kcL96NV7AYWwrJ4bpCc0V 2nZoFK6zlpuTpqTElEUb6Cbs3zloisk8dsmCoZwbyhtRUGOdKQO0T00p+lxh 4upwWa.ZTEcXpjl5SMQDjDGX+eF+YP9q8D+wxWzZq5poCdIetU99I1+kiBYC ekAiEaFNb8D1AXF+0W4GNZf8ZcEbU60nkkh8MkSFsZRpqVNG8sX+0t6Z+3k+ fKC7ZPqpjlUlls7xPx8sLjkGwN9TqejVF3RQA28x.77Y4XwHj6fnG4xPvy8x vw6e3wi9A7sg26V7rzb3a8BwNU1EG4cONW9khfy0ye8W4A3b8+Y4bK0mqdM4 dWrrGOW1zOd8U94v+Xzs5WCumXDvUjZ+Ll8D9wC7Dni5tpVglOZzKwemVZjT Wb+ARB4t1OHas99g3k85O7Jan4bmp4KpJ43R0vW35tXGXq7b0juH65ZziWzo V8TqyW6b1V+Y4Bk4zkvKwGNlllIpFaChe45UVZpl1ufbaI.tVqamYZ5d3Meo qO3VpiV1m6VVd+gGZWU7E6QA0Z6zEh20HqlH9fVVYr0DH1uQOcV2pFzWUn3s 1.kMq+RQhiLUmc0q5nOWgFup8Llv2hlbSz.KZp3HYScqtfl0Sr.YhCJkmqsO lKNfhP21IYK2S7tRSwYpp1Zspjg7EGufdU53zkb4.wupG2HqmYpTLPn3XYid 9XzCQhe+pRypZiEeZw3EkxFw9pxxVFKQ7lEkE54zposn07lO2Py422LUVwXY hOnZJVz1RGsF.mK9HYdq.B7DGLaQSwrAP9hOpTC5qf.xcWPyb6Nba4Pq6fFO cAaxAQhOIqlZtQqhGrJtP2QSfWTQyrp+IWax5011oTkn1zAKltZ+p7aeCUls dkEkJoqiyWu14z4kIbsgdh2etpYRC4Upb0y39h2naorr1SwCwCV1IybyXdAH Lbk0uuMBmEKZ0.awDu3TJRhpAia7MqrVWbFpJQbXihhOQn88Up3jRYMZJuuL La.BumLLWbxUUcyFznHugPbqh7ocaFhl.WHfKvKZQg18sk3.Rj3.J7eibra7 inMcMp4lRi3DxlqlBzD5Lw29Fsp2cc7TZuRwL5LPCk0vdRgQyDeROuVVwmRh xcug3sUsp4TnOXxwdqgy1cruap3FGWqCtAJZan3WM5BkXO4L1fhib.u23.hc uGCyHIqrYwQ5NFKkl0KlWqPIx9aLyG6NGFmaOGxttDO5DMsiZXqS7sqhUz4n iLMryNwFqxtNbBst6NSjDtbApoeQKI5ZX7LJgrWSciM9yIRNpQBcdoraUQxT UUll9xYzZdilhvo5gxEuergs8TOx6NsT2tx5R84MIFXWoA13YjKESlzPZglN KicGoQhCKo4K+bLEan.4QrEocDxpAUmJ1uzbQEEqqi1QyPzF2YxyVLSRYVYf bwuMiNqgpynCjE1Ql8rY9h+iRNQ3SAC9eKjMJ9DRV.PCHT4EcFS2LfGB7P57 urrTapcsOB3QD9L8omBvX.FaAobOUSAbBfSDu3b6dC.lBvT6Y3S6l0BzLflI dg8bh3eInfNHrRVN4GXytRcgPNEcStGiRl8ETvC.4yPjEWaJup0ttC7.FmsX iFwLxCYLxfGatvE+JOhwHqkxcZmyE.NlgI6clrz.nDFhL11KTpZfkJN72sVY iTink4YVDqikDQLgNK3BJkmawsN1lqnTaHprummEkLRY2bSa8LkaAhHeZqvZ ob14JJVlqh.aEj4N0LlBBsDMzhRVqhlspkfQVPq8Vne0oZGHcPXYrXeuDZOa 0WMnPpce0bMw8BkyD+hoyUWt3Wjk8YTojx6KmVqqQBUJg7g5ISJckBr8SkTi RgTPqpynnP1js.JRr2TCkcaU5WJm7I1bUh2PA.bPIheyXlL1l7G.zITo9LC2 FfjINVUZlPo.9jwAsLFdein7weTQYnZUhCthl.vFnTxtzP1TEh+qgl1nBaPF kj5gAXTPFkzRPyUNRrutghVQ6C5.BEdm3rvbLDejBjBzDwQJZGkotywqfRCu WccobwxdNiLiJpmWQY9ZL4zU5NR3fiRtkiLZCKUX4+dpzF2XlRiq3eLZ6d4C wI3xGf.fra4lD9dZFR42LIeSt6g7maMuzAsy159VVXL4ac2nviv2hqRXy7sQ A+zD8pqJlnJtcEs92sygBf.mC+Ityqz6RR6CPJKKLNOl6Kuke9nDxdW5X89I eUAAa1UEjvWbUXvS+UEDx8bNutEluIWTP5e2tm.WTXhQEI049umf6s4Ox6If E7whgXMFLOcl6KSzjYlwrY.q.jxEYxfvaH3FxrgvZnmFJngfYnRFBigZXnAF JegRWnnEJWgDUHEERNg.SHmDpGgdQHLDZ.gpOnzCp6ffNngCh2frMHXCpzfp LnACZtfVKnrB5nftInSBhifhHnBB5dfdGHyAJbflFniAJWfVEnNAJRfPDH+. JNfXCnu.5JfbBHi.BHftAnV.BDfp.nF.p..qevwGL5AEdvXGTzAkbv9FrsAA aPmFDnAkYvPFjhAMXP8EDccLac7XcrVczTcDScTQcjPczOcrNcDNcDMcDLcL KcTJczHcTGczEcjDcLCcrAcT.cb9bL7bj5bb4bD3bL1bzzbry94wJij4PwqV i0P8Taf3QaDGgaKeEmpxOOb0k6dsj8ChblsIozW9ElLijCnp1zzUeGewb8D8 SoyHh8Bgfqzc6LR1H9Maamg8NntKhPeGewZIj0U2CMG3oBhSW9Mh788TQOed peDtgdtucymZtgfUzlwML34manUzB95R2HlgtuIszsEyP7Yb3lvLL7uCLC0U mguAnUC+2m53ZKV2Auw6tsOPRirj18rKX7S62+zA8O8l9mda+SG1+z65e5nm 8LsEckz9Qg2SU5kH+goZStqXlwaRLyv6LlIOLir+XFtwOeE1Rs3W2C0ZVzTr 7XnS3jXkwNQ01oq5ON84dJBCZy.CwgP4npMTxEmIPYQhsNAj+HHpuzpgQ2ZO AxdFuaco8oz7YxkOd6mROP+Kvuuvyk4uoVeeZoqUHa4sXDim2BypnGvrJ4dl UOcVS3CvZh+A1gG6sM2f+Pr9fMw5iyGbaNCdNHX09iffsxbJ3ALmBebyIXuI C3hM74.dOOl2Aam872HHysOoRejSJD6ALpBCWq.9ckE0+71XZsElU37RPzv. TCJ39IbwyprrGvrB4.k001u8GmowSHhOvWMLoqjWxE0UnHaYiZTmqW1dNK6H YCkcuiRsunA4luLKYzt1w4u18+SBAwTB -----------end_max5_patcher----------- </code></pre> A 3rd way of fixing this issue would be more difficult. You have to edit the CC routing in the Software of your MBFM. &nbsp; See also this statement from TK for more details: ""> if you use the "Ctrlr" plugin you also have to edit the panel to reflect CC changes made in the Firmware. I prefer my "MBFM Patchselector" Device, because it was easier to build for me as a Firmware + Ctrlr Panel Hack. I hope my Max device will help you a little. best regards Thomasch

Hallo Rolf, welcher Filter eignet sich am besten - eine schwierige Frage, wenn man sich nicht von vornherein auf einen bestimmten Soundcharakter festlegen möchte. Warum stattest du deinen Synth dann nicht einfach mit mehreren verschiedenen Filterboards aus, die sich umschalten lassen?

Ein sehr interressantes Projekt. Sollen die getriggerten Sounds denn wie die "üblichen" Stepdance Sounds klingen, oder willst du damit völlig artfremde Sounds ansteuern? Eine 1:1 Umsetzung für normale Stepsounds wird nämlich schwierig, bzw wird nur eingeschränkt oder über Umwege zu erreichen sein. Ich spreche hier speziell von den Sounds, die erzeugt werden, wenn der Fuß nicht gerade aufgesetzt wird, sondern über den Boden geschliffen wird. Da wirst du beim Tanzen einen Workaround finden müssen. Bei E-Drums gibt es da ja ein ähnliches Problem, wenn man die Wisch bzw Rührbewegungen den Besens simulieren will. Möglicherweise würde es für soetwas auch Sinn machen zusätzlich noch Beschleunigungs- und Gyro-Sensoren einzubauen, die bspw dann ausgewertet werden, sobald der Trigger für die Ferse aufgesetzt ist. So könntest du Bewegungen(Beschleunigungssensor) oder bestimmte Fußstellungen (Gyroskop) mit als Trigger benutzen. Der Fersensensor müßte bspw für die Wischtechnik 2 Funktionen erfüllen, einmal um den Sound beim Aufsetzen zu triggern (normales Stepgeräusch) und zusätzlich als Switch für die Vertikalen Daten des Beschleunigungsensor, der ja nur ausgelesen werden soll, wenn der Fußballen den Boden berührt (Schleifgeräusch). Sowas erfordert mit Sicherheit viel "Herumexperimentiererei". Ist sicher auch die Frage, wie "ausgebufft" das ganze am Ende denn sein soll - reichen 3 einfache Trigger Zonen Pro Fuß oder darfs auch gern aufwändiger sein. Die Sensoren kann man zur Not übrigens sogar aus nem Wii Controller klauen. ...und die Verwendung eines Wii Controller auf herkömmliche Weise, nämlich in der Hand wäre für dich ne weitere Möglichkeit noch zusätzliche Parameter zu steuern. Die größten Erfahrungen mit diesen Sensoren dürften sicherlich die Bastelkollegen vom Flugmodellbau, speziell die Quadrocopter Fraktion haben, da gibts in diversen Foren viel Text und im Zweifelsfall bestimmt auch Hilfe zum Thema Beschleunigungssensoren und Gyros. Die haben auch mit der Wii und ihren Bauteilen schon experimentiert Ein einfaches Beispiel für eine musikalische Anwendung von solchen Sensoren hat uns damals beim Studium ein Dozent vorgeführt, der sich einen Controller (Finger)Ring gebaut hatte. Damit hat er dann effektvoll in der Luft herumgewischt und auf diese Weise an diversen Soundparametern "geschraubt". Fand ich damals irgenwie cool. :smile: Gruß Thomasch

Der Nachteil bei MIDI ist die relativ geringe Auflösung mit 7 Bit, da geb ich dir recht. In der Praxis halte ich das aber für weniger dramatisch, als auf die Fernsteuermöglichkeiten von Cutoff und Resonanz verzichten zu müssen. In meinen Songs mache ich beispielsweise intensiv Gebrauch von Automatisierung durch die DAW, daher halte ich das persönlich auch für wichtiger, als eine superfeine "analoge" Auflösung. Pro und Contra: Poti to CV Midi to CV Hohe Auflösung +++ --- Automation n.V. +++ Speicherung n.V. +++ Mehrfachbelegung n.V. +++ Sieht doch nicht schlecht aus. Evtl macht es ja Sinn eine Beschleunigungsfunktion für die Encoder zu Implementieren. Je schneller du drehst, um so größer werden die Parametersprünge, ansonsten kurbelst du dich ja tot. Gruß Thomasch

Danke für den Tip mit dem USB Repeater. Braucht man da für jedes Adapterpärchen ein eigenes Netzwerkkabel, oder kann man die auch in ein bestehendes Netzwerk einstöpseln?

Das Optimum würdest du wohl erreichen, wenn du es hinbekommst Hobby und Beruf zu vereinen.

Hallo Leute, Ich hab folgende Problemstellung: Es soll eine MIDI Verbindung zwischen der Wallbox im Aufnahmeraum und dem Rechner im Regieraum hergestellt werden. Dabei sind allerdings Kabellängen von ca. 30m zu erwarten. Normale MIDI Verbindungen funktionieren meines Wissens nach bis maximal 10-15m. Für ne USB Verbindung zwischen PC in der Regie und nem MIDI-Interface im Aufnahmeraum dürften die 30m auch zu weit sein. Wie überbrückt man am besten eine solch hohe Distanz? Gesucht wird eine bezahlbare Möglichkeit. Gruß Thomasch

Hallo Rolf, Warum benutzt du eigentlich Potis statt Encoder? Beim Laden und Speichern von Sound Presets oder dem Fernsteuern von MIDI Parametern durch die DAW würden die aktuell eingestellten Werte der Potis ja nicht mitberücksichtigt. Da könnte man bestimmt auch etwas mit Abholmodus für die Potis programmieren, ich persönlich empfinde die Abholmethode eher als unvollkommenen Workaround. Unter anderem, weil man sich nicht darauf verlassen kann, daß die Markierung auf der Potikappe auch dem internen Wert entspricht, oder ob der interne Wert erst noch abgeholt werden muß. Evtl macht es ja Sinn, statt der verwendeten Potis eher auf Encoder mit LED Kranz zu setzen. So kannst du Speichern, Laden, Fernsteuern und selbst Mehrfachbelegungen der Encoder sind möglich.

Sieht toll aus dein Case. Würde mich übrigens auch interessieren, was das für Buttons sind.

hat deine neue soundkarte eigentlich eine midischnittstelle, damit du deinen synth auch über midi ansteuern kannst?

Nunja optimal ist das bei einer Roundtrip Latenz von 100ms dann doch eher nicht. Ich würde das eher als "worst case" bezeichnen. Mehr als 7-10ms sollten es definitiv nicht sein, insbesondere wenn du externes Equipment wie z.B. deinen AVR-Synthi in die DAW einbinden willst. Lade einfach mal einen der Testsongs, die beim Cubase sicherlich dabei waren um Prozessorlast beim Abspielen zu erzeugen. Danach drehst du die Latenz so lange herunter, bis du den Punkt erreichst an dem die Wiedergabe anfängt zu knacksen. Dann die Latenz wieder vergrößern, bis es nicht mehr knackst. DIe Latenz ist übrigens von der Prozessorlast abhängig. Bei kleinen Projekten mit wenigen Plugins und geringer Pozessorauslastung kannst du kürzere Latenzen benutzen und umgekehrt. P.S. Die Latenz die im Treiber angezeigt wird ist übrigens nur ein theoretischer Wert, der durch Treiberfehler in der Realität abweicht. Die Roundtrip Latenz ergibt sich aus Eingangs- + Ausgangs Latenz. Falls du es genau wissen möchtest, dann verbinde Eingang und Ausgang der Karte mit einem Kabel, lege eine Spur mit einem Audiofile in Cubase an und route die Spur auf den Ausgang in dem dein Patchkabel steckt. Danach eine zweite Spur erstellen und mit dieser Spur den Eingang der Karte in dem das andere Ende des Patchkabels steckt wieder aufnehmen. Durch die Latenz wird die neu aufgenommene Spur leicht versetzt sein, diesen Versatz zur Originalspur kannst du dann einfach in der Zeitlinie ablesen. Wichtig!!! --> Die aufzunehmende Spur nicht auf den Hardwareausgang routen, sonst gibt das ein böses Feedback. Das Hardware Monitoring des Line Eingangs im Output Mixer der Soundkarte auch stumm schalten!

hallo rolf, consumer interfaces sind ja gewöhnlich nicht für ihre kurzen latenzzeiten berühmt. auf was für roundtrip latenzen kommst du unter asio mit der creative?

Du mußt eigentlich nur wissen, ob du eine hohe oder niedrige Auflösung willst. Die -64 bis +63 Variante wirkt erstmal intuitiver beim Soundfrickeln, die 0 bis127 Variante bietet allerdings mehr diskrete Schritte. Mehr Möglichkeiten haste nicht.

Andererseits... Wenn du die Detune Werte auch via MIDI ändern willst, dann macht eine Auflösung von 0-127 oder -64 bis +63 durchaus Sinn.

Klingt vernünftig. :)

Na wenn du keinen Wert darauf legst das sauber auf die Centskala zu legen, dann kannste auch den vollen 127er Bereich ausnutzen und das Multiplizieren weglassen. Je feiner, um so genauer kannst du mit Schwebungen spielen.

Wie machst du dann die Umrechnung von 0-99(+1) zu 0-127 ? Die native Auflösung 0-127 pro Halbton macht ja ein sauberes Cent Tuning eigentlich unmöglich. EDIT: Bzw 0-255 pro Halbton

Hallo Rolf, Ich finde das sieht um einiges besser und übersichtlicher aus, als der Urentwurf! Den Wertebereich für Detune würde ich noch auf 99 begrenzen, denn die vollen 100 brauchste zum detunen eh nicht, das entspricht ja einem vollen Halbton und für Halbtöne hast du ja den Transpose Wert. Dadurch würde auch die Leerstelle zwischen Zahl und > nicht "gefressen". Den Slider würd ich komplett wegrationalisieren und die Sliderfunktion direkt auf die Zahlen legen. Durch den rechts eingesparten Platz könntest du auch die Pfeile/Zahlen noch weiter auseinander ziehen, damit man besser trifft. Das sieht auf dem Bild noch etwas eng beieinander aus. Ansonsten - Daumen hoch! Gruß Thomasch