Shreddage 3 MIDI and Keyswitches

[HarvestWombs]

I just installed Shreddage 3 Jupiter and have been playing around with it for a while.

I'm still disappointed you haven't implemented a "tuning" feature by now. I play in F#, and while it is possible to tune Kontakt down three semitones, and set the Transpose nob up nine semitones, I end up losing those nine notes on the top end of the "playable range".

For your future question: Why am I transposing the midi up, if I can tune Kontakt down?
Answer: To keep everything in line. If I tune Kontakt down, I am still left with an A key that sounds like an F#. Really hard to write music like that.

For the money, I think it's awesome, I've been using Shreddage 2 for years. But there's plenty more options you guys failed to perfect.

The idea of the "playable range" is limiting this VST by a lot. If you guys want to hardcode keyswitches into the engine, then fine... But move them out of the way. The keyswitch for Strum Mode starts at F#7 when you could move them all the way to B8, and leave us an extra octave of space to fine tune or use custom keyswitches.

[zircon]

By "tuning" feature, do you mean artificially extending the range of certain strings?

[HarvestWombs]

By "tuning" feature, do you mean artificially extending the range of certain strings?

That would be the most preferred option, for sheer customizability.
But you could even get away with moving the whole "playable area" up or down so the MIDI keys match the note. Like I said previously, if i drop the master tuning down three steps, the Transpose nob should be able to account for that.

[EvilDragon]

Keyswitches are mostly not hardcoded, many of them are adjustable. However strum keyswitches are directly tied to the end of playable range.

Unfortunately doing what you suggest (shifting the playable range according to instrument tuning knob) is probably not going to happen, because it would have to account for the whole range of that control, which is +/-3 octaves. Limiting it to just a certain range of instrument tuning knob makes no sense at all IMHO (you're either all in or nothing). Plus, they are completely different things - keycolors relate to MIDI notes, instrument tuning is something entirely different. Not to mention it would create a pretty nasty domino effect with all the other keyswitch areas... Plus I don't think that doing that sort of thing is NKS-compliant (which we must have, doing anything against NKS guidelines is out of question).

[HarvestWombs]

However strum keyswitches are directly tied to the end of playable range.

That was exactly my point. The playable range is limited by the key switches that surround it.
The Transpose knob only works one way from my experience, as turning it down (or is it up?) conflicts with the "same key", "rake?" Etc switches that lie just below the A key. (Sorry I'm typing this from memory as I don't have my workstation in front me)

To sum this all up. I'm forced to write in Drop A, and then turn the master tuning down to my preferred tuning. All in, or nothing I guess.

[EvilDragon]

Transpose down works just fine, it's just not going to play anything below the lowest mapped note if it goes out of mapped range. It's also only valid for blue keys, it's not going to trigger any keyswitches outside of playable range if they're there.

Either way, strum and rake/same key KS are there for convenience and are tied to the playable range for a good reason (because it's convenient to have them there when playing in realtime rather than punching in notes in piano roll). This is likely not going to change.

[pryzmusic]

To sum this all up. I'm forced to write in Drop A, and then turn the master tuning down to my preferred tuning. All in, or nothing I guess.

This doesn't require any more than a trivial amount of extra work that you can template, especially since you say you frequently like to write in Drop F#.

1. Tune the instrument down 3 semitones.
2. Use your DAW's transpose feature on the MIDI clip to not lose your 9 notes at the top (true MIDI transpose rather than being limited by playable range).
3. If you want to keep the keyswitches in place so they match where Shreddage says they are, just write them on a duplicate MIDI track to the same channel that has a +0 transpose.

We have already thought heavily on solving the problem of retuning and keyswitch ranges. Shreddage 3 is an engine that will be continually expanded with a lot of features, and the reason we didn't get to tuning is because it's frankly an obscure feature that most people aren't going to use. What you consider important and necessary is not reflective of a desire from the entire userbase. There were many more important features to get right, such as the chord engine, which took a while. But the chord engine, for example, is designed to work on an internal dynamic array of the instrument tuning, one that is capable of reacting to changes in tuning. So the code design is ready for updates when we decide to do them, and that's the important thing.

It isn't impossible to implement a retuning system that dynamically pushes keyswitches out of the way and I have ideas on how it would work. But we can not guarantee a specific date on when we will have the time to do this. Specifically, if you look in TACT, you see articulations have menus where you select their keyswitches. Pushing the ranges dynamically from retuning would necessitate those menu entries to update in real-time. It would also extend into shifting the key colors over. This is a primary example of something that has to have a significant amendment to code design, since these menu selections are static and can not be renamed, the way Kontakt's internal interface widgets work (NI's fault, not ours). It requires a workaround, and workarounds take time (and priority).

Of course, we could just ignore the disconnected UI and update the keyranges anyway, but I think you'd agree it's bad form for a $150 piece of professional software to ignore interface considerations like that. There are standards at play here.

tl;dr I'm sorry this is a major issue for you. Try the solution i gave above, it gives you the best experience (notes actually representing their real pitch, no playable range mistakes) for minimal extra work, and hold out for an eventual update where we can do tuning properly in-engine.

[EvilDragon]

since these menu selections are static and can not be renamed

Actually they can be renamed using set_menu_item_str(). But it's quite a pretty big amount of code refactoring no matter how you go about it.

[Mavoz]

I've been using a piece of software that I'm loving...Gig Performer...and you can do transposing via a midi in block....

in fact it lets you customise pretty much anything...

the only strange thing was that the Vibrato setting could not be learned..or given a Kontakt automation id.....it appears to be hard coded to the 'Mod Wheel' CC1 (I guess that is by design)

However again with Gig Performer you can program it to still learn a widget control for the mod wheel on CC1...

[EvilDragon]

the only strange thing was that the Vibrato setting could not be learned..or given a Kontakt automation id.....it appears to be hard coded to the 'Mod Wheel' CC1 (I guess that is by design)

This is correct.