Oasys Wishlist

[domc]

That would so awesome. IMHO this should be what the next generation Electribe is. All the best of KARMA and arp/grid drum programming.

edit: ideally I need to write/draw up a proper explanation of this idea, rather than just vague blurbage ... I'll try doing that later}

OK, I've been racking my brains over the past few days about how to do this. I'm sure Korg engineers/Stephen/Daz/others have better ideas, but I thought I'd share with everyone the solution I came up with of how to add to the existing Karma drum facilities to make the next generation drum sequencer.

At the back of my mind were the following constaints:
1) To use the existing Karma architecture - rather than suggests changes which in all likelihood would be very hard to implement (at least in the Oasys for now).
2) To use some additional pages on the operating system - in order to do something different and helpful to the user) - but keep new pages to an absolute minimum so that the design/implementation path for Korg was as easy as possible.
3) To add the features which (I believe) are missing to really utilise the drums on the oasys. I'm talking here about the sequencing of sounds, rather than the quality of the drum sounds (which is a separate subject discussed briefly at the end). The advanced features of Karma drums are fantastic (swing adjustment, improvisation, bends) but its the easy stuff which is currently hard to do. Here is my list of additional features I was trying to build into the system.
a) Complete (and importantly easy) control for the user over which drums (and at what volume) play in every scene.
b) A grid system, adjustable by touchsceen (which the whole community has been clamouring for) which allows user patterns to be created. To be really useful this had to tie into the existing template banks for Karma drums. But it needed to allow the user to do the basic things available on any hardware drum machine (or the reason drum machine with which I'm very familiar), i.e. v.easy to program something like:
Scene 1: Kick 4 to the floor.
Scene 2: Adds closed hi hat.
Scene 3: Adds cymbal
Scene 4: Adds rev cymbal
Scene 5: Takes off cymbal - adds percussion.
Scene 6: Loses the kick, but allows everything else.
And it needed to do this in an easy way, without the user having to delve deep into the land of Karma parameters to try and figure out for Scene 6 whether there was an internal parameter in the depths of Karma parameters that could be adjusted to do this.
c) A system which allowed the user access to all the great Karma drum banks, but in such a way that if you found a template where you liked the kick drum beat for instance, but wanted to change the hi-hat pattern or the percussion, it would allow you to do this in a fast and intuitive manner.


OK so here's what I came up with: 3 extra pages on the Karma tab, accessible from one new sub-tab called 'Drum control' (there's space for this extra sub-tab if you look closely). The first of these pages controls which drums are sounding in any scene, and the second and third are almost identical, controlling which of the templates is playing for any scene and allowing users to see and create their own templates.

Page 1: So this page allows the user to select which drums sound (by toggling the on/off switches) and the volume of each drum (by setting the numbers in the right hand side). But it allows the user to do it for each scene - so horizontally you see columns representing each scene. And the way it does this should be relatively easy to implement, as it uses the existing Karma architeture - specifically the parameter "Row 1....7 Vel. Offset" (described on page 863 of the original paper Parameter Guide for the Oasys). If a row is turned off, then a scene change transmits -127 to this parameter, otherwise it transmits the value next to the on/off switch. This parameter is freely changeable today (if we had an RTC which showed them) so there should be no change in how the current Karma system works to do this. It would just require implementation that the press of a scene button transmitted the appropriate new values to these parameters of the GE. This would be a first step up in user flexibility.

The last column allows the user to select which note (ie drum sound) is played by the each line of the 21 different drum rhythms (again a parameter already in the karma design [and if you wanted to be really flash you could have this be different for each of the scenes although this is not reflected on my diagram])

Page 2,3: So these are the pages which allow programming of the grids/drum rhythms. These pages are a little more complex but I'll try and explain.
Page 2 maps out the grid over the first 32 sub beats. Page 3 maps out the grid over the second 32 sub beats. Other than that they are identical, so I've only drawn one illustration of the first 32 sub beats. [If upon design on the touch screen, this resulted in boxes too narrow to use with the touchscreen, then I would suggest moving to 4 pages instead showing 16 sub-beats each rather than 32]. As many of you are aware, drum GEs have 3 templates of 8 lines each, so in this depiction these are on top of each other with the bottom one representing the kick, snare and tom pattern, the middle representing the hi-hat, ride and cymbal and the top one representing percussion.

The left hand side shows the selected scene, and the templates played in each of these scenes. i.e. so this is designed to allow the user to select a different template for each of the 3 drum modules for each scene. Again the karma architecture already allows this to happen (as explained on page 868 of the original Paper version parameter guide). The only thing I've added is that each of the templates is given a name, so the user can select which template to load up for each scene with a name which has meaning. This allows the user to easily mix and match different kicks with different hi-hat patterns very quickly and intuitively.
Ideally, the user would also be able to set at the top left the default length of the pattern for each scene [eg a 64 sub-beat pattern, or just a 16 sub-beat pattern] AND (and I've not included this on the drawing) the rhythm multiplier for each pattern for each scene (eg. 100% or 50% or 75% etc.).
Again all of these parameters already exist within Karma, it would just involve a little bit of programming to change these values in the GE at each scene change, but all the existing Karma architeture remains in place unchanged.



So having loaded up the template for each scene, the grid system now allows the user to quickly alter them as well, adding or subtracting hits as they see fit, to mimic exactly what they want to do, and the buttons on the bottom left allow these to be saved (they would need to be saved to be used by the scene changes). The altered grids can be individually saved (eg template 1,2 or 3) to user banks (ie tap that button "save to template no 1" and a dialog comes up allowing you to save the first template grid to any one of a number of user locations with a name of your choice), but the templates can also be loaded and saved to existing patterns, allowing better integration between the existing Karma 2 features and the RPPR features.

So that's it. At the end of this you end up with 8 scenes which are totally customisable in terms of which drums/patterns play in each one, but you haven't lost any of the ability to then still improvise on each of these scenes, perform bends or any of the other great real-time features which we all love. None of the exsiting GEs already programmed are lost or need to be changed in any way (causing work for Stephen / korg or mucking up any of the 1000s of existing combis/programs) - the switches, buttons could all remain the same. [In fact the combination of 8 scene changes (with different templates) together with the 3 drums on/off switches would give designers access to more that 24 customisable different drum beats per GE at the touch of a couple of buttons]

But how easy would this system be to implement? Only Stephen/Korg can tell us that but I have a couple of thoughts.
1) The first change would be that a scene change would need to change a few more of the GE parameters than currently stored with the sliders/switches. Specifically, the each of the three templates, each drum's velocity level, the length of the three patterns and the three rhythm multipliers. However given that the architecture is already set up to change a large number of GE parameters upon a scene change, I don't think it should be too hard to add a few more.
2) The second change would be that the size of the existing GE files would be increased to hold the new parameters (the template settings, volume settings etc for scene changes). I've no idea how hard this would be, but I'd have hoped this was one of the easier things to change. I would have thought that you could load all the existing GE files easily into this new architeture, as you could program it so that if they didn't have the new parameters for scene changes, then it just loaded the original default values into all the columns on page 1 and used the same templates, lengths etc for page 2.
3) Obviously the pages would have to be designed and programmed into the new OS (which would require some work from Korg and prob Stephen) - but by limiting it to three pages this is hopefully not a huge burden - and (to me at least) seeing as it uses the existing Karma architeture for actually changing parameters in the GE, and there are no new GE parameters suggested, this shouldn't be too difficult a job - it's just about building an interface to change those parameters (and the MS-20EXs interface is much more flash).


So this really helps the live performance side, but what about the sequencing side. Well this really depends. If the system is altered so that Karma can be played by midi, then this is easy. If not then I don't know.
Supposing yes, then the midi track will record which notes are held down/which scenes are seleced in Karma, so it would be easy to record which of the 8 possible scenes are playing as the base of a track. The actual content of those 8 scenes can then be altered independently by playing with the Drum controls tab. In this way it would be easy to build up a sequence with 10 bars playing scene 1 (just kick and ride) with new drums being added on top by changing the scene at subsequent bars. Then (without having to change the sequence) you could change the ride pattern as you felt like it, by going to the Drum Control of the GE generating your drum beat and changing the template for the ride pattern.

Lastly, what about the drum sounds themselves mentioned right at the start. Well to start with, you could just used the existing system (again making it easier to implement) but if you want to go one step further you could create a Drum EXi which allows the creation of 21 drum sounds from synthetic parameters or from the existing samples which the GE can then play. The tone adjust settings of this EXi would allow for the volume of each drum to be controlled and for things such as pitch, reverse etc, some basic effects (eg all the parameters of a normal drum sampler) to be manipulated and in this way you could created rolls etc with steadily increasing volume - not by having to sequence directly sequence this, but by recording sysex messages for tone adjust showing the volume increasing for a particular drum.

This should give all the flexibility we need to do most things I've wanted to do from a drum sequencing point of view as easily as possible - and hopefully with a minimum impact on programming, altering the existing system.

Cheers, Domc

[domc]

4) Routing midi tracks to Karma

I've begged to do this for years, even since Karma Workstation and KARMA 1, and recently as well. But it's a sequencer issue. It seems you should not have to use an external sequencer to accomplish this.

I've been tyring to wrap my brain around this issue as well, given its relavance to drum sequencing - and also as it seems to be a much asked for request by other users than just myself.

I see the problem for the Korg engineers:
- what do you record on the midi track, do you record the key presses that trigger Karma, or do you record the midi output from karma when the user selects to record. Then when you playback is this input put into Karma, or just straight to the midi instruments.

Basically, the traditional midi record ability is inadequate in coping with the advanced midi generator/real time controller that is Karma, as users would like the ability to record just the triggering input (so that this could be rearranged at a later date) or the output (as they are finished, or they want to use karma for another track).

So I came to the conclusion, that for best functionality, the sequencer of the Oasys really needs to be changed slightly to mould itself to the Karma concept. Specifically I think that there should be four new 'karma midi' tracks included in the sequencer. These in concept would store karma parameters to generate a track, whereas the midi track would continue to store (as it does today) the output of Karma on the track. Then the user would select for playback whether an instrument assigned to a track controlled by Karma was triggered by the karma track, or played directly from the midi track with no Karma. In this way it would easy for a user to record the way a track sounded with karma set up a certain way, then change a couple of karma parameters and change how it sounded with the new settings (something which is possible today - but only if you use and external sequencer.)

In terms of specifics the karma midi tracks would store the parameters associated with the triggering of Karma (the GE number, the scene, the notes pressed, the pads hit, the positions of the buttons and the sliders, any other GE paramaters that could change and if the tone adjust / mixer settings were changed these as well) for the 4 Karma modules. These could then be editable in the same way midi tracks are today (or hopefully via graphs/grids in the new OS).

The normal midi tracks would remain unchanged also storing tone adjust/mixer settings - so both the midi karma track and the normal midi track contain all the details for the controlling of the specific instrument and its performance over time.

Applying this to the drum sequencer idea preceeding this one, the drum sequence would be recorded as a karma midi track with the changes in scene being recorded on the karma midi track - so it would be easy to modify the contents of any particular scene using the drum control sheets - and it would be easy to edit which scene was playing at any time by modifying the karma midi track.

I wasn't particularly happy, when I came to this conclusion, that really to get the best out of sequencing karma, you need to assign the four karma modules their own midi tracks (as this creates more work for the programmers at Korg, and we all want an extra 16 midi tracks/16 stereo audio tracks as well). But the more I thought about it, the more you see the advantages of this system (which is effectively the same as having that four track external sequencer residing with the Oasys). The reality is that Workstations with Karma arene't the same as workstations without, so it should be no real surprise that the sequencer that fitted the old style workstation, does not have the features to truly ustilise (and sequence) Karma. All the more reason that the sequencer overhall (that is hopefully happening at the moment) is upgraded to truly work with (and sequence) Karma modules as well.

Regards, Domc

[StephenKay]

Basically, the traditional midi record ability is inadequate in coping with the advanced midi generator/real time controller that is Karma, as users would like the ability to record just the triggering input (so that this could be rearranged at a later date) or the output (as they are finished, or they want to use karma for another track).

So I came to the conclusion, that for best functionality, the sequencer of the Oasys really needs to be changed slightly to mould itself to the Karma concept. Specifically I think that there should be four new 'karma midi' tracks included in the sequencer. These in concept would store karma parameters to generate a track, whereas the midi track would continue to store (as it does today) the output of Karma on the track.

Interesting idea. That might have some advantages, but probably more work than something like this:

I was thinking about simply having a parameter for a MIDI Track, such as a "Send To KARMA" checkbox. When checked, the data in that track is sent to the KARMA Modules, and if any of them are listening to that channel, they react as if you were playing it from the keyboard live. So, you record your global channel button presses and Chords onto a track on Ch01 (for example), then check the box and it goes directly to KARMA. Presently, there is no "pathway" from the output of a track to the input of KARMA. But that seems not so difficult to me (hah! I always love it when people say "seems not so difficult" about things they are not truly involved with. Now I'm doing it about a different area of the synth. )

I plan to respond in more detail to your diagrams above when I have some time. Some interesting ideas there, somewhat similar to some ideas I have been working on. Probably not doable in quite that manner, but....well...let me respond.

[thekeymaster]

I like where this is going.It all seems feasable then.Interesting.

[domc]

I was thinking about simply having a parameter for a MIDI Track, such as a "Send To KARMA" checkbox. When checked, the data in that track is sent to the KARMA Modules, and if any of them are listening to that channel, they react as if you were playing it from the keyboard live. So, you record your global channel button presses and Chords onto a track on Ch01 (for example), then check the box and it goes directly to KARMA. Presently, there is no "pathway" from the output of a track to the input of KARMA. But that seems not so difficult to me (hah! I always love it when people say "seems not so difficult" about things they are not truly involved with. Now I'm doing it about a different area of the synth. )

Hi Stephen, I did originally go down a similar path to this with an option like a check box that chose how the midi track was interpretted. However, as I thought about a number of practical situations it seemed to have a couple of disadvantages.
Firstly, recording to midi tracks via this methodolody seemed problematic and secondly editing seemed to favour a distinction in the type of track.

To elaborate on recording first of all. You wouldn't want to lose the ability to record the real time output of karma. But then how would this work in reality. If you had your check box ticked and the midi notes on the midi track were directed to Karma and produced many more midi notes, would these then be saved in a buffer. If you stopped recording after say 10 bars, would the first 10 bars then be replaced with the full output from Karma, with the remaining [60] or so bars still being the midi input pre karma. If so how could you then play that track to check if you liked it as you would need to manually switch the check box half way through to adjust for the post karma and then pre karma sets of midi data. Or if you did record the full 60 bars, would this all be placed in a buffer (effectively the same as having a separate track) so that you could press compare and go back to the mid sequence pre Karma. All these recording / playback issues seemed to go away if you had separate karma and normal midi tracks and you could select which of them controlled the output of sound engine.

Secondly on editing, it seems to me that the editing of a karma midi track and that of a normal track would require pretty different editors (assuming for a second that we'll get an enhanced editor in OS 2).
Again I'll explain with an example. Even ignoring all my ideas about an enhanced karma drum machine, with the drum GEs we have today, if I wanted to record a drum track pre karma, all I'd want to record on the track is holding down one note, coupled with scene changes, and movement to switches/sliders to turn certain sets of drums on and off at certain times. So the ideal interface for this would be something showing the graphical representation of the scenes, switches, sliders etc, as well as the few notes that were effectively acting as triggers.

If we compare that to the editor (like that which we have today) to record and represent the actual midi notes produced from that combination of switches and keys, then the focus is not on any of the karma sliders/switches/scenes (you don't need to record their individual movements - just the resultant midi output) but on the vast array of midi notes along with their associated velocities, CCs etc.

So you could have a smart editor, which decided whether to edit a pre-karma set of midi data or a post karma set of midi data by examining the type of data recorded, or you could eliminate the need for smart interpretation by making it automatic depending on the track where the data was stored (i.e separate karma midi tracks). Given the conceptual problems I was having with recording/playback, I went with the latter.

So although on the face of it the four extra karma midi tracks seems like it's the more complicated route, I actually think that it is maybe simpler than the check box route, once you've had to work out ways of coding all the recording/playback potential problems of having pre Karma and post Karma midi on the same track and of having editors to edit the pretty different data sets. That was the logic which drove me to the separate karma-midi tracks anyway.

Kind regards, Domc

[StephenKay]

Hi Stephen, I did originally go down a similar path to this with an option like a check box that chose how the midi track was interpretted. However, as I thought about a number of practical situations it seemed to have a couple of disadvantages.
Firstly, recording to midi tracks via this methodolody seemed problematic and secondly editing seemed to favour a distinction in the type of track.

To be honest, I don't see the problem(s).

To elaborate on recording first of all. You wouldn't want to lose the ability to record the real time output of karma. But then how would this work in reality. If you had your check box ticked and the midi notes on the midi track were directed to Karma and produced many more midi notes, would these then be saved in a buffer. If you stopped recording after say 10 bars, would the first 10 bars then be replaced with the full output from Karma, with the remaining [60] or so bars still being the midi input pre karma. If so how could you then play that track to check if you liked it as you would need to manually switch the check box half way through to adjust for the post karma and then pre karma sets of midi data. Or if you did record the full 60 bars, would this all be placed in a buffer (effectively the same as having a separate track) so that you could press compare and go back to the mid sequence pre Karma. All these recording / playback issues seemed to go away if you had separate karma and normal midi tracks and you could select which of them controlled the output of sound engine.

Again, I don't see the problems. It's all about MIDI Channels. Record a track of data on Channel 1 (GCh) as per normal - pads, scene changes, keyboard playing, chords in the LH area, etc.

Typically, the KARMA section has MIDI Ch GCh (Ch01) as the Input Channel. Then the output of the 4 KARMA Modules go to Ch02, Ch03, Ch04, Ch05.

So, Control Track is set to Ch01, and [x]Send To KARMA, and the output of KARMA goes to Ch 2,3,4,5. Set up 4 more tracks on those channels, and Multi-Rec record on them while Ch01 is playing. That's all it needs, to me. That's how I do it with Digital Performer and my own KARMA Software. You play one track, one one channel, into KARMA, and record the results onto 4 other tracks, set to different channels.

Secondly on editing, it seems to me that the editing of a karma midi track and that of a normal track would require pretty different editors (assuming for a second that we'll get an enhanced editor in OS 2).

That's a big assumption, and who said anything about OS 2.0? Why wouldn't the next thing be 1.3, 1.4? Just playing devil's advocate...

Again I'll explain with an example. Even ignoring all my ideas about an enhanced karma drum machine, with the drum GEs we have today, if I wanted to record a drum track pre karma, all I'd want to record on the track is holding down one note, coupled with scene changes, and movement to switches/sliders to turn certain sets of drums on and off at certain times. So the ideal interface for this would be something showing the graphical representation of the scenes, switches, sliders etc, as well as the few notes that were effectively acting as triggers.

I'm just trying to be realistic. Sure, you could envision that, but in reality, it's still MIDI data, and it's a long note, with various controllers happening. Actually, for my own KARMA software, I envision a timeline-like interface at some point, with graphical events for pad pushes, slider movements, scene changes etc. Drag a scene change from one place to the other. But do you really think Korg is going to create 4 new tracks for KARMA alone, with all sorts of special graphical editing features? When there are all sorts of other issues with the sequencer? Believe me, I've been working with them for a long time, and I don't. Although, since this is a wishlist, you can wish for anything.

So although on the face of it the four extra karma midi tracks seems like it's the more complicated route, I actually think that it is maybe simpler than the check box route, once you've had to work out ways of coding all the recording/playback potential problems of having pre Karma and post Karma midi on the same track and of having editors to edit the pretty different data sets. That was the logic which drove me to the separate karma-midi tracks anyway.

Thanks for all the great ideas and time you've put into this, I have to disagree with you on this particular thing. Adding 4 special purpose tracks, with special purpose editing and graphic tools, is 1000 times more effort and difficulty than a checkbox on each track. And I don't think the MIDI routing issues present a problem, as I outlined above. Anyway, I think the checkbox is doable, while the rest probably isn't.

[domc]

Thanks for all the great ideas and time you've put into this, I have to disagree with you on this particular thing. Adding 4 special purpose tracks, with special purpose editing and graphic tools, is 1000 times more effort and difficulty than a checkbox on each track. And I don't think the MIDI routing issues present a problem, as I outlined above. Anyway, I think the checkbox is doable, while the rest probably isn't.

Hey don't worry about disagreeing; it's great to get some feedback from someone involved in the development. I've been trying to provoke Jerry and Dan into some discussion on the sequencer but they've been immune to gentle probing on the seq issue for almost a year now

So, Control Track is set to Ch01, and [x]Send To KARMA, and the output of KARMA goes to Ch 2,3,4,5. Set up 4 more tracks on those channels, and Multi-Rec record on them while Ch01 is playing. That's all it needs, to me. That's how I do it with Digital Performer and my own KARMA Software. You play one track, one one channel, into KARMA, and record the results onto 4 other tracks, set to different channels.

I agree the check box idea is probably much more likely to happen. Now that I understand how you envisage it working, I don't think it's really that different from what I was suggesting as well. You're separating the channel that records pre-Karma midi from the ones that record the post-Karma midi. While your example takes the example of starting with something like a premade Combi in seq mode, playing one channel to generate four different instrument tracks, I envisage me needing four separate pre-karma midi tracks:
I would like to lay down a drum track using Karma; then I want to select a bass instrument and using one of your great bass playing GEs I would record a second selection of Karma input notes (and switch/slider movements) for this. Then I would like to add a trance arpeggiator on track 3 and record the 3rd part. Likewise for track 4 with a pad. The only difference between how I would like to work and your suggestion is that in my method I would need to record 4 midi tracks pre-karma (as they would be using different base notes in each one with different switch/slider movements and I'd like to be able to subsequently edit each of them independently) vs the one you've suggested in your example for the global track.

With the 16 midi channel limit (which I currently find is a big limitation), then I'm obviously not keen to take up 4 of these channels for recording the pre-karma midi. Hence my desire for 4 extra channels. If the 16 regular midi channels are expanded to something larger in the next OS (eg 24 or 32) (which I know everyone would like) then the relevance of having 4 extra Karma midi tracks falls away and I would be very happy with your check box implementation as you've described it. [Obviously with only the choice of check box implementation and the current limit of 16 midi tracks or nothing then I'd take the check box in a heart beat, but everything points to the need for more midi channels, check box Karma midi implementation or not.]

:
Again I'll explain with an example. Even ignoring all my ideas about an enhanced karma drum machine, with the drum GEs we have today, if I wanted to record a drum track pre karma, all I'd want to record on the track is holding down one note, coupled with scene changes, and movement to switches/sliders to turn certain sets of drums on and off at certain times. So the ideal interface for this would be something showing the graphical representation of the scenes, switches, sliders etc, as well as the few notes that were effectively acting as triggers.

I'm just trying to be realistic. Sure, you could envision that, but in reality, it's still MIDI data, and it's a long note, with various controllers happening. Actually, for my own KARMA software, I envision a timeline-like interface at some point, with graphical events for pad pushes, slider movements, scene changes etc. Drag a scene change from one place to the other. But do you really think Korg is going to create 4 new tracks for KARMA alone, with all sorts of special graphical editing features? When there are all sorts of other issues with the sequencer?

Yeh, I guess a separate editior is more of a wish list item - I should pull my feet back on the ground as I'm definitely trying to be realistic with most of my ideas (to give them a tiny hope of coming to fruition). What you describe in your Karma software is exactly the place I'm trying to get to where you can move scene changes from one place to another easily. I agree it's just midi, so could be edited using the same midi editor as that for normal midi. It's just that I'd like that editor to have some of the features you've describe and I imagine, to make the manipulation of the pre-karma midi track easy to do.

Thanks for the feedback and interesting discussion.

Cheers, Domc

[bo.h]

I was thinking about simply having a parameter for a MIDI Track, such as a "Send To KARMA" checkbox. When checked, the data in that track is sent to the KARMA Modules, and if any of them are listening to that channel, they react as if you were playing it from the keyboard live. So, you record your global channel button presses and Chords onto a track on Ch01 (for example), then check the box and it goes directly to KARMA. Presently, there is no "pathway" from the output of a track to the input of KARMA. But that seems not so difficult to me (hah! I always love it when people say "seems not so difficult" about things they are not truly involved with. Now I'm doing it about a different area of the synth. )

I love this idea, its something I've been missing from day one!
And I totally agree, It doesnt seem so difficult.

Im not at the O right now, maybe its already in there (I havent found it yet),
but I would also like to be able to trigger RPPR's from a track,
seems to be along your thoughts?

[Derm]

I've been trying to provoke Jerry and Dan into some discussion on the sequencer but they've been immune to gentle probing on the seq issue for almost a year now

Hi Dom,
Jerry & Dan are both on the record in this forum as saying "they would welcome improvements to the sequencer", or words to that effect.
My understanding is that it is not their department. I think that aspect of Oasys development happens in Japan. As much as I would love to hear that they are beavering away night & day to bring us the sequencer we want in the next OS update, nobody from Korg will ever comment on future plans.

[bo.h]

I have three check-box related wishes:

* Track to KARMA
* Track to RPPR
* Track to RPPR to KARMA

And then, on top on that, a wish for a way to add info when triggering RPPR from a Track, maybe by using sysex msg instead of note-on, to achive:

* T(n) transposition n semitones
* I(n) inversion around n
* R retrograde
* ... Note-map and other filters and functions
* stack the filters and functions above

Why not a whole section of filters for MIDI, like the ones for Audio?
Yes, more MIDI routing, filtering and triggering including the Track as source.

Maybe KARMA and RPPR are filters?

[StephenKay]

I've posted some comments about the drum grid stuff in this thread:

http://www.korgforums.com/forum/phpBB2/ ... 541#165541

[jerrythek]

I've been trying to provoke Jerry and Dan into some discussion on the sequencer but they've been immune to gentle probing on the seq issue for almost a year now

Hi Dom,
Jerry & Dan are both on the record in this forum as saying "they would welcome improvements to the sequencer", or words to that effect.
My understanding is that it is not their department. I think that aspect of Oasys development happens in Japan. As much as I would love to hear that they are beavering away night & day to bring us the sequencer we want in the next OS update, nobody from Korg will ever comment on future plans.

Hi folks:

Life and business are quite busy these days, so I don't have time I used to to just chat as much. Sorry about that.

Yes, we don't and won't comment on future plans. But we listen. All the time. I often clip parts of threads to share them with Korg inc. staff to bring subjects and your feedback to the "surface" of our attention. So talking, suggesting, dreaming does have a beneficial affect, I promise you.

But not always in the time frame you want.

Let me clarify some roles for you.

I am the Korg Technology Senior Product Manager at Korg USA. That encompasses responsibilities for almost all the tech products that Korg makes and sells in the US. I work VERY closely with Korg Inc on everything they do, and work with Dan and the R&D group as well. So I am in the middle of most of the things, although I certainly don't do the coding or mechanical design etc.



Dan is the Product Manager at Korg R&D. The synthesis side of the OASYS is certainly their "baby" and Dan in core to our spec development for all their efforts. He is detailed, intelligent and cares a lot about all aspects of the instruments, even the parts that his group doesn't actually work on. Like the sequencer, or the disk mode...

Stephen is an independent contractor with Korg, and so you might be tempted to look at him as only the KARMA-man, but he has worked with us for many, many years on a lot of projects so he is a valuable partner who offers plenty of ideas and insights on spec, voicing etc. But as he clearly states, he is independent and his comments are his own, not anything official from Korg, or even always an insider view.

So it is great for any and all of us to discuss things as creative individual when it comes to future things, but don't expect that any one of us is going to be the "go to" person for the final decisions that Korg Inc makes. We all play roles in the process, but we don't make the final decisions, only some of us are part of the group that does.

And we won't and can't actually talk specific plans, details or even promise "intentions". That isn't a negative, or a shut-down of the discussion, and don't read anything deeper into it. It's just meant to say that we won't be "drawn out" into a discussion for the purpose of getting answers about the future.

But we're happy to chat with you when we can, and give some insights into how things work.

Sorry for the ramble - I hope it helps.

Jerry

[domc]

Thanks for the comments Jerry. It is clear that you, Dan, Stephen and other members of the Korg/Oasys team care deeply about this product and its development - that's manifested itself in the quality of the instrument so far and your continued participation in these forums, and for which most of us here are very thankful.

If all these dreams are not wasted, then permit my imagination to run wild for a few more minutes. [I'm going on holiday for 9 days starting later today so you and Stephen should have a bit of a break from my recent spate of postings!]

The discussions of the past few weeks have had the benefit of adding clarity to my dreams following discussions on the Karma drum sequencing idea.

My current dream entails the following:

1) The first step needs to be the ability to record Karma pre-midifying. There's so much advanced sequencing functionality already built into Karma, that it's a huge disadvantage not being able to take true advantage of it at the moment. Effectively all you need to do is store the scene selection along with the other button slider positions (and possibly some mixer/tone adjust settings as well), so in my dream world the editor to this will be very user friendly: Something like - it'd be easy to move a scene selection 3 from bar 5 to bar 10 by double touching the bar on touchscreen and moving to different place - something like this rather than the list based editor of today.
Anyway fancy editor or not, checkbox implementation or not, a whole host of good things start to become possible if you allow pre-Karma midi to be recorded (with the scene changes then possible to drive different drum patterns, different guitar patterns, different bass patterns etc as part of your prerecorded sequence)

2) Next step would be the enhanced Karma implementation that Stephen's just talked about on the New Karma sequencing idea thread. http://www.korgforums.com/forum/phpBB2/ ... hp?t=22548 [I wish I knew how to point it to the right position half way down the thread but I don't ]. With liberty from Stephen, I'm calling it an enhanced Karma II rather than Karma III as the number of total GE paramaters is not changing, nor is the implementation of how the Oasys takes those original pre Karma midi notes and manipulates them using GE parameters into post Karma midi. Whats being suggested is just changes to the GE files/and the system when a scene button is pressed, so that at this time a whole number more of those GE parameters are changed than those currently derived from the 8 switches/sliders as described by Stephen.

Together with a couple of other changes (maybe the ability to alter another 32 parameters within the oasys like I suggested, not assigned to sliders or selected by every scene, but just adjustable within the Oasys rather than on external software) then I think a whole new world opens up which I'll explain next!

3) New world - you can now create custom control pages for different RTC models - I'm calling them EXKi (Extension Karma Instruments). This is something I've been thinking of for a while as a way to marry up the incredible flexbility of Karma, with the need for a more intuitive interface for controlling some aspects of it. Don't get me wrong, I love the fact that it is so flexible. With all the Karma II parameters adjustable almost anything you want to do is possible. But sometimes you'd like to be able to set how it responds to a particular scene change via a visual display rather than experiments with the switches. The primary example of this is the drum sequencer. In many circumstances it would make sense to set the drum templates via a visual display - and my drum template diagram earlier is one example of how this might be implemented, but I'm sure there could be many others.

What I'm not thinking of here is a full implementation of Stephen's GE software on the Oasys - which I'm thinking to be fairly difficult to do - but also doesn't really fully address what I'm trying to do. I'm thinking of custom OS pages, probably specific to a certain instrument/RTC model (i.e the drum control template page) that focus the user on the key aspects for that instrument that make sense to be changed per scene (for drums these would be items such as the templates used, the rhythm multiplier and length parameters per template and the drum volumes) and have a smart interface to allow a user to change these items intuitively (and work by moving those 32 static parameters I mentioned or the 32 parameters changeable by scene). This still leaves the 32 existing GE RTP parameters to work in exactly the same way, allowing real time manipulation/improvisation which we all love.

But drums aren't the only thing this is applicable to. You could do exactly the same thing for a strumming guitar EXKi (where the custom OS pages showed the rhythm template and other things) to allow the quick creation of different guitar strumming patterns per scene (again allowing you to sequence them if number 1 is implemented). Or for a bass guitar EXKi which helped generate custom riffs. There are many, many conceptual EXKi possible, and they would be like next gen instruments in themselves, allowing the convenience of setting up different playing styles that can be easily and intuitively created and sequenced (via scene changes), but losing none of the existing improvisation ability.

As most of these EXKi wouldn't be available day 1, you'd have a standard one page, like the matrix Stephen suggested, which allowed the manipulation of those 32 items, but not in a manner customised to be helpful to the user.

[EDIT - having the 32 items set by the RTC is slightly different to Stephen's suggestion where these parameters would be full customisable, but here like with the RTC models themselves, I think some standardisation would actually help]

4) Ok here I go into loopy loopy land, but here goes. All of what I've described is actually not that far from where we are today. As I mentioned all of the functionality of responding to the GE parameters is already residing within the Oasys today. Yes the sequencing of pre-Karma midi via a checkbox or the like needs some work. Yes the size of the GEs and the implementation to change various parameters upon a scene change needs some system modification. But none of these seem like they're unsurpassable. Most of them are in fact variations/ or slight additions to ideas that Stephen (who obviously knows the system) has said he's been thinking about.

All except the custom control pages I've described which need to reside within the Oasys that provide the control of these 32 or 64 extra parameters via effectively custom pages/graphics on the screen. These would be quite a bit of work to create - but with amazing benefits.

But how about making this part of the system open source!! All we're talking about is giving the user say 3 design pages (per RTC model), and letting them designing graphics that pull up items such as templates to allow the user to set how those 32 or 64 parameters are set within the system and for scene changes. This would provide amazing flexibility and lead to a whole community of different RTC/EXKi instruments each designed for their own purpose/instrument.

[EDIT: The reason I thought this aspect was most applicable to open source was because neither Stephen nor Korg would have to give up any proprietary info to do this. All we're talking about are graphics pages to control GE parameters that are already well know and described. In addition you might need a little bit of processor time to do simple calcs for EXKi specific parameters that you may want to show on the screen. The idea is similar in concept to how Kontakt II's internal programming language has opened a door to the creation of midi manipulators with their own custom graphical controls. However in this case, the tools for the creation of widely different and instrument customisable midi streams are already there in Karma II, but the ability to create some new graphical OS control pages for them would open a large new door for the possibilities of Karma]



My imaginations run riot enough!

Cheers, Domc

[bo.h]

Maybe KARMA and RPPR are filters?

Doh! I meant effects, not filters, MIDI-effects, similar to the existing audio-effects.

I would like to be able to route MIDI just like we currently route audio.
We do route MIDI in various places like "KARMA->GE Setup/Key Zones->MIDI I/O" and "Timbre Parameter->MIDI".
Why not open up the routning and generalize it like "IFX->Routing" or something similar and do it in one place?
In this way each of the four KARMA modules would be a MIDI-effect (why restrict it to be four?) and even RPPR would be an effect.

At the bottom left of the new "MIDI-Routing" page we would have the MIDI-sources (Keyboard, External-In, 16 MIDI-tracks),
and at the bottom right the MIDI-sinks (External-Out, 16 Timbres/Synths),
and in the middle all effects (KARMA-modules, RPPR's, other MIDI-altering/adding/filtering effects).
(Unfortunately I have no idea how to add an image in this forum )

I understand that this would require some (minor) coding, but why not start small, why not start with a checkbox or three?

[elvisjohndowson]

Hi,
I was just assembling a set of samples on the OASYS today. Some of the samples contain loops (guitar tremolo riffs) played with a particular chord A3# and E4, for example.

Now what I'm trying to do is layer this riff, with other sample sounds. Therefore each sample with its component takes (A3# and E4) would be stored in a multisample and then I'd create a program out of this.

The problem with such programs created from such samples is that when you play it at a note, other than the original key, the tempo either increases or decreases.

I would like to see a real-time sample time stretch feature incorporated into the OASYS, that allows you to overcome these temporal effects. We have the time stretch feature implemented for offline processing already. If it could be implemented for a short note range, say 4 or 5 keys up or down, it would help create programs which won't exhibit these temporal effects.

Elvis Dowson