Jump to content

Thomasch

Members
  • Posts

    129
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Thomasch

  1. 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?

  2. 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

  3. 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:

    post-10094-0-53851900-1380068759_thumb.j

    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.

  4. 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>

  5. 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...

  6. ...

    [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.

    ...

     

    @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. :(

  7. 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

  8. 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?

     

  9. 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

  10. Hallo Thomasch und noch frohe Ostern  :rolleyes:

     

    Die Verwendung von einigen Potis statt Encoder war die Empfehlung eines Freundes (Musiker). Zum Beispiel ist das Cutoff-Poti für die Realtime-Steuerung direkt mit CV-Eingang des Filters verbunden. Dadurch hat man bei einer hohen Resonance-Einstellung eine viel bessere Auflösung und kann es feiner einstellen. Die digitale Steuerung der Filter ist weiterhin möglich. Aber das ist nur eine Idee von vielen. Das Design ist noch nicht endgültig

    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.                       +++     

     

     

     

    Damit es aber hier nicht so langweilig wird, ein ganz kleiner Vorgeschmack auf die neue ADSR-Funktion in meinem AVR-Synth nach einer Idee von Wolfgang aus dem CC2-Forum.

    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

  11. 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

     

  12. 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.

  13. Hallo Thomasch

     

    In "Cubase LE 6" kann ich die Creative SoundBlaster ASIO von 1-200msec einstellen. Standardeinstellung ist 50mse. Bei 1msec bemerke ich Tonstörungen wenn ich am PC Fenster öffne oder andere Dinge tue. Bei 5msec habe ich keine Störungen. Ich habe die Latenz auf der Standardeinstellung von 50msec belassen, da mir dies optimal erscheint.

    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!

  14. Ja stimmt. An Midi hab ich jetzt gar nicht gedacht. Mal schaun wie ich das jetzt umsetze.

    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.

  15. Den fehlenden Rest hab ich einfach untern Tisch fallen gelassen.

    Ich werde das jetzt so gestalten das ich auf der Anzeige Detune-Werte von -64 und +64 darstelle und diese intern mit 2 multipliziere.

    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.

  16. Hallo zusammen

    Ich habe das Menü für die Oszillator Einstellung nach einer Idee von Thomasch geändert. Es sieht jetzt übersichtlicher aus und ist einfacher zu bedienen. Um die Werte für Transpose und Detune zu ändern, tippt man einfach auf den Zahlenwert zwischen den beiden Pfeilen. Diese fangen an zu blinken und man kann jetzt über den Fader oder den ext. Drehencoder den Wert verändern.

    Achso.. hab ich ganz vergessen. Der AVR-Synthi besitzt jetzt einen Drehencoder. Damit lassen sich die Parameter viel leichter programmieren als über das Touch-Display. Gerade wenn man sehr kleine Wertänderungen programmieren möchte wzB Schwebungseffekte funktioniert das über den Drehencoder sehr genau.

    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

×
×
  • Create New...