has the midi architecture been updated?

Stromer

Does the situation with the midi-cc's has changed or is it still that the midi mapping is stored within the sound xml's and that for each sound and midi-channel you have to do a new midi learning? If it's still so in version #3, it makes it impossible to work with the Deluge in a professional studio environment, where is no time to do 1584 midi learnings for all 99 default sounds (and how to do that with a limited number of 999 sounds?), where everything has to go fast and effective.

Before i degrade my Deluge for that reason being a simple loop-player, i want to ask what the philosophie is behind this architecture? It makes no sense to me but maybe to the Deluge team? Maybe i havn't understood the real reason for doing it this way and not in a way which could make the Deluge to one of the a top machines in all studios in the world? Cause the sounds of the Deluge are great, but the midi-architecture up to version 2.1.4 still sucks! I will update to version #3 when the main bugs are fixed and only if midi-cc's are becoming globally.

Icoustik

There's nothing new about the midi implementation in terms of CC's in 3.0.2 (the latest firmware) in the way you're referring to.

3.0.2 is however very stable, and fixes many bugs etc. If you're only gonna use Deluge as a loop player you'd still want to install the firmware.

Its not difficult to batch-copy a set of midi mappings to hundreds or thousands of xml files at once, in seconds.
You can effectively make your own custom midi implementation(s) and then copy it to all your presets.

The program Notepad++ is free, and can do this, using the Find and replace function

Icoustik

Program: https://notepad-plus-plus.org/

How to: https://youtube.com/watch?v=9j8Djan7Pm0

Stromer

I did the batching with python but it really sucks to do it that way. And its maximum non flexible if you want to change a parameter.

Thats the way i do the midi mapping in my Arduino Control-Change Arranger box:

• not def - ;CC 000
  QM Mod Wheel;CC 001

• not def - ;CC 002

• not def - ;CC 003

• not def - ;CC 004
  QM Glide ;CC 005

• not def - ;CC 006

• Volume - ;CC 007
• not def - ;CC 008
• not def - ;CC 009

• Panpot - ;CC 010
  QM Sound-Vol;CC 011
  QM Inst/Wave;CC 012

• not def - ;CC 013
  QM Tune ;CC 014
  QM VCF Drive;CC 015
  QM Cutoff ;CC 016
  QM Resonance;CC 017
  QM EG Attack;CC 018
  QM EG Decay ;CC 019
  QM EG Sust ;CC 020
  QM EG Releas;CC 021

• not def - ;CC 022

• not def - ;CC 023
• not def - ;CC 024

• not def - ;CC 025
  QM LFO Depth;CC 026
  QM LFO Wave ;CC 027
  QM LFO Rate ;CC 028

• not def - ;CC 029
  DL OscA Vol ;CC 030
  DL OscB Vol ;CC 031

• not def - ;CC 032

• not def - ;CC 033

• not def - ;CC 034
  DL OscA Ptch;CC 035
  DL Tune/Ptch;CC 036
  DL Bitcrush ;CC 037
  DL Cutoff ;CC 038
  DL Resonance;CC 039
  DL EG1 Attck;CC 040
  DL EG1 Decay;CC 041
  DL EG1 Sust ;CC 042
  DL EG1 Relea;CC 043
  DL EG2 Attck;CC 044
  DL EG2 Decay;CC 045
  DL EG2 Sust ;CC 046
  DL EG2 Relea;CC 047
  DL Mod FX ;CC 048
  DL LFO1 Rate;CC 049
  DL LFO2 Rate;CC 050
  DL OscA PhWi;CC 051
  DL OscB PhWi;CC 052
  DL Bass Vol ;CC 053
  DL Bass Freq;CC 054
  DL Trebl Vol;CC 055
  DL Trebl Frq;CC 056
  DL Noise Vil;CC 057
  DL Stutter ;CC 058
  DL Delayrate;CC 059
  DL Delay FB ;CC 060
  DL Rverb Snd;CC 061
  DL Rverb Vol;CC 062
  DL HPF Freq ;CC 063
  DL HPF Reso ;CC 064

• not def - ;CC 065

• not def - ;CC 066
• not def - ;CC 067
• not def - ;CC 068
• not def - ;CC 069

• not def - ;CC 070
  ET Resonance;CC 071

• not def - ;CC 072
  ET EG Attack;CC 073
  ET Cutoff ;CC 074

• not def - ;CC 075

• not def - ;CC 076
• not def - ;CC 077
• not def - ;CC 078

• not def - ;CC 079
  ET OsC Pitch;CC 080
  ET OsC Glide;CC 081
  ET OsC Edit ;CC 082
  ET OsC Fltr ;CC 083

• not def - ;CC 084
  ET Mod-Depth;CC 085
  ET Mod-Speed;CC 086
  ET Insert FX;CC 087

• not def - ;CC 088

• not def - ;CC 089

• not def - ;CC 090
  QM FX1 send ;CC 091
  QM FX2 send ;CC 092

• not def - ;CC 093

• not def - ;CC 094
• not def - ;CC 095
• not def - ;CC 096
• not def - ;CC 097
• not def - ;CC 098
• not def - ;CC 099
• not def - ;CC 100

• not def - ;CC 101
  ET Mast FX x;CC 102
  ET Mast FX y;CC 103
  ET Insert FX;CC 104
  ET MaFX send;CC 105
  ET MaFX OnOf;CC 106

• not def - ;CC 107

• not def - ;CC 108
• not def - ;CC 109
• not def - ;CC 110
• not def - ;CC 111
• not def - ;CC 112
• not def - ;CC 113
• not def - ;CC 114
• not def - ;CC 115
• not def - ;CC 116
• not def - ;CC 117
• not def - ;CC 118
• not def - ;CC 119
• not def - ;CC 120
• not def - ;CC 121
• not def - ;CC 122
• not def - ;CC 123
• not def - ;CC 124
• not def - ;CC 125
• not def - ;CC 126
• not def - ;CC 127

127 x parameter name + cc-number

very easy!!

What is the problem to do it with a simple config file like above?

manateemilitia

@Stromer said:

i want to ask what the philosophie is behind this architecture?

From a development standpoint, I'm very curious about this too. Maybe it's because of my background in service-oriented architecture but it seems very odd to me that the control layer (including MIDI), and the synthesizer/sample playback layer aren't exactly two separate elements that interact, but are rather enmeshed. There's no real judgement on my part, but the lack of functionality segregation has impacted my workflow fairly significantly (and many others, as the numerous threads on related topics indicate).