eDRUMin 1.6.2 BETA

[Rob]

Very strange issue I have characterized on this build. On input 2 of ED10 I have a PDX-8 connected to a stereo connection. This pad is my small rack tom. I have hit, SS and RS midi notes set up. The SS is a midi note for a rack tambourine. I’ve noticed that, no change to my playing style, when I’m jamming on the rim for the tambourine I get an annoying Tom head hit about once a measure. When I turn off autoselect and focused just on the pad I couldn’t duplicate the problem. However, when I turn autoselect back on the problem reoccurs.

Should be fixed in build 4.

eDRUMin_Control_PC_1.6.2.4.zip

eDRUMin_Control_OSX_1.6.2.4.zip

[Dadwrshpdrum]

Very strange issue I have characterized on this build. On input 2 of ED10 I have a PDX-8 connected to a stereo connection. This pad is my small rack tom. I have hit, SS and RS midi notes set up. The SS is a midi note for a rack tambourine. I’ve noticed that, no change to my playing style, when I’m jamming on the rim for the tambourine I get an annoying Tom head hit about once a measure. When I turn off autoselect and focused just on the pad I couldn’t duplicate the problem. However, when I turn autoselect back on the problem reoccurs.

Should be fixed in build 4.

eDRUMin_Control_PC_1.6.2.4.zip

eDRUMin_Control_OSX_1.6.2.4.zip

Confirmed fixed. Thanks! I thought I was going crazy and my playing technique had regressed….

[monospace]

Updating to build 4, I got the same "You have unsaved changes..." screen I reported on build 3 when trying to update the ED4. This time the app locked up, but didn't crash. After force quitting and restarting, the ED4 appears to have updated regardless.

[monospace]

I can definitely confirm that Sidesticks are way easier to trigger in this new build, even on my modified old Hart Dynamics snare.

[hang12]

Sounds like I'm ready to take requests for version 1.7.

Since the eDRUMin is the front end of any given eDRUM equation, the ease of faster cross-over re-assign-ability between more than one Drum environment (soft or hard) could/should be a way forward - since it seems like much of the basic trigger assignment has been covered in versions to date.
I am now using two eDRUMin10's and a TMC-6, utilising 4 foot controls (HH pedal, Roland KD-120 Kick and two other Roland KT-10 kicks), 11 mesh or rubber pads (incl. two snares with 3 zone heads plus rims), VH-12 HH, 7 Roland / 1 Yamaha cymbals (all have bow/edge/bell), 2 BT-1's (sidestick on snare, cowbell etc on a tom).
So it is a lot to account for all of these MIDI channel/note assignments, nevermind all the other specifically tweaked parameters per trigger. Simple math for 2 or 3 notes per trigger (x's 22 inputs for the two eDRUMin's), plus HH, is easily 50+ MIDI note assignments per BANK.

I originally assigned the eDRUMins to a TD-10 and a TD-20, then graduated to the various SD3 libraries using Roland mapping, but focused on really just one SD3 set while trying to figure out many of the aspects of the eDRUMin world and the SD3 'midi mapping towards many articulations' world. Finally I am getting a better grasp on re-mapping the many SD3 kits within their various libraries (to the eDRUMin map) but that is a large endeavor in itself, plus trying to figure out file management save variations (kit level, map level, SD3 file level, DAW host file level).
A lot of SD3 libraries look nothing like my hardware trigger set-up - it's like re-cutting pieces for a wacky jigsaw puzzle for note re-assignment sake.
And I'd like to still use the TD-10/20 but it's not an easy re-assignment backwards, without picking through all the individual triggers.

After using this eDRUMin setup for 10 months for two eDRUMin10's, I have a few update or new feature suggestions...

Save device preset(s) to somewhere other than desktop (a default folder somewhere)

Device snapshots - they don't have to be instant, but they'd be nice to just recall inside the control app, rather than having to do the assorted computer file management routines.

Bank snapshot dumps, to copy elsewhere or store away, without the 3 other banks involved

Bank snapshot names and/or...
Note Bank labelling - name, date, description

Trigger swapping or copying would be cool without saving somewhere and re-loading

Input naming (maybe more helpful across two or three devices - especially if input swapping is implemented and one doesn't have to literally hit the hardware to ID the 'current focused' on-screen input, to act upon some file management routine)

Bank copy/swap - like 1 to 4, or 3 to 2

File Dump of bank(s) of inputs with assigned note names - output to columnated browser or a text file (comma or tab separated or whatever might open in a spreadsheet) - this could be very handy for checking assignment/re-assignment for bank copy/swap

Implement an auto-firmware update function - like 'two devices detected - firmware will be updated' when a new app version is opened for the first time. Is there a reason for us to know that the firmware needs updating?

Great product - I really enjoy using it!

[Dadwrshpdrum]

I second the idea of hang12 as it relates to note bank enhancements. I really like the idea of saving global note bank snapshots (or preset, whatever is the best terminology) separate from the input presets and/or device snapshots. In the past I think I made a post about additional note banks. If the note banks were archivable then I don’t think I would really need additional note banks (more than 4).

If technically possible positional sensing rimshots would be nice (shallow vs deep).

If technically possible, positional sensing setting CC vs Note is selectable by note bank. This could be solved by the aforementioned note bank snapshots.

My use case is that EZD2 uses CC, but SSD5.5 does not. I also use a slave Td-17 module sometimes which does not support HH levels. So instead of just changing a note bank to SSD5.5 I also need to change the config of the snare’s positional sensing to note. The device snapshot has helped, but it is a bit difficult to maintain configuration control (eg trigger settings) between the snapshots to keep the core device settings the same (eg trigger settings) over time. Similar thought is HH levels. I know someone asked before about making that note bank selectable, and you responded that is not feasible. I understand the limitations and how device snapshots is the best option to switch between HH CC to HH levels. If there was a way to make/group a family of device snapshots such that core parameters are kept the same within the family. So if I make a change to a member of a snapshot family for a decay parameter (for example) that change is made across all members of the snapshot family. Whereas members of the family can have different settings for positional sensing Cc vs Note and HH CC vs HH Levels (for example) that would be useful.

Finally, in a previous post you had commented that eDRUMin benefits from the same engine as MIDIexpression (I am paraphrasing so I could be off on my terminology) so MIDI transformer is built into eDRUMin. I went into the manual for MIDIexpression to see what that was. A lot of it was beyond my understanding (I’m a novice at the power of MIDI), but some features I saw as a benefit to me. I don’t have SD3 so there is only so much I can do with EZD2 and SSD5.5. I think transformer would open a few more possibilities for me. For example, I think if I read manual correctly, I could program a HH pedal note to send a HH pedal note and a tambourine midi note. I thought there was velocity gates in there too so a high velocity HH bow note could send a tambourine midi note as well. I understand with SD3 this is easily done, but for those of us with simpler tools I can’t really do that.

Thanks for the great product!

[Rob]

Thanks for the inputs guys. I agree with the notion that eDRUMin is the front end to any software/hardware, and making it malleable enough to quickly adapt to any environment should be given more consideration. At the same time, I don't want to make the system more difficult for new users.

I think the first step is to move the drum maps onto the hardware. That way triggers can be assigned a kit piece identifier, which is used to look up note numbers on the fly based on the currently selected drum map. Changing the current drum map would update all note assignments accordingly. I'm thinking 24 different kit pieces, about 12 of which can be hardcoded based on drum maps, and the rest can be user defined. I don't know...have to think about it.

[Dadwrshpdrum]

Thanks for the inputs guys. I agree with the notion that eDRUMin is the front end to any software/hardware, and making it malleable enough to quickly adapt to any environment should be given more consideration. At the same time, I don't want to make the system more difficult for new users.

I think the first step is to move the drum maps onto the hardware. That way triggers can be assigned a kit piece identifier, which is used to look up note numbers on the fly based on the currently selected drum map. Changing the current drum map would update all note assignments accordingly. I'm thinking 24 different kit pieces, about 12 of which can be hardcoded based on drum maps, and the rest can be user defined. I don't know...have to think about it.

I appreciate the consideration on ease of use. I do believe if note banks were added to the preset manager in the same manner as a device snapshot I think that would be similar and easy for most users that already use the preset manager. So, for example, I select note bank 1 on any input and then select preset manager. Then the preset manager opens like normal with all of the normal look. I can save, load, and modify just like any other preset. Maybe, similar to the existing preset manager when loading a pad input, when you are ready to load a note bank preset there is a pop that asks if you want to make a global change or just load the note bank for the selected input. I would suggest you move the note bank indicators up on the app to where the devices are shown and/or the pads icons so they are selectable with preset manager open. That would be a useful change in general, in my opinion, such that the selected note bank for the active input is always open regardless even if the velocity graph is selected.

Edit: last thought if you chose this route I don’t think saving or modifying a note bank would require a pop up to ask if this a global change or just for the selected input. Saving or modifying a note bank would always be global.

[hang12]

...That way triggers can be assigned a kit piece identifier, which is used to look up note numbers on the fly based on the currently selected drum map. Changing the current drum map would update all note assignments accordingly. I'm thinking 24 different kit pieces, about 12 of which can be hardcoded based on drum maps, and the rest can be user defined. I don't know...have to think about it.

I like the concept of a kit piece identifier. It would seem to offer a better starting point than just the quasi-random way that I have plugged everything in across 2 eDRUMin10's. Not that I didn't give it a good deal of thought beforehand for the layout, but it's definitely not defined like the back of a TD-20, 30, etc with everything 'hard' labelled (K Sn HH T1 T2...) including the nebulous AUX 1-4 inputs. And I started with only 1 eDRUMin10, i.e. I didn't order two at the same time, so things do evolve - but the last thing I want to do at this point is yank and swap cables around.
One of my requests is for an (editable) overview, somehow - that allows me to visualize all of one or both device's settings. All triggers would be best. SD3 is my main thrust currently and I think I can (at this point) modify the SD3's MIDI mappings for most all of the other SD3 library kits I encounter - other than the percussion kit - because I have basically finally established/settled on a kit piece layout in eDRUMin land.
But for all the GM and other assorted non-GM mapped drum libraries and layouts - anywhere from older Kurzweil and Roland drum layouts, to Native Instrument's various World beat and percussion plugin offerings, to UVI's Beatbox emulators, etc, etc... - there's just a ton of translation required on the front end. So on any given day, how I do I navigate between all these worlds? Short of say developing an in-line re-mapper app in Max as a go between with eDRUMin and that very large world of sound sources, it'd hopefully be easiest at the eDRUMin source, rather than having to learn all of those widely varied individual sound sources re-mapping requirements (if they even have any). Such as Rob has done by offering the various company's mappings, although they are editable and assignable at an individual trigger level, not as a complete editable overview level.
And as a keyboardist primarily, I can at the press of a button have any patch from any/all these other sound sources show up as playable from my master keyboard. How do we get the same situ to happen from a master drum kit?
Just dreamin'...

[vdrummerguy]

These are all well thought out suggestions, but also what about the linking one input to another so that it mimics all the same notes as the one linked to, e.g. the multiple pads linked to one hh pedal.

Also, I always wondered how this updating to newer versions worked, as I'm on an older version now, generally have everything working the way I want, and I'm a little scared to upgrade that it might screw up my settings, but still would like to upgrade for the new features.