The No.1 Website for Pro Audio
The Korg Logue User Oscillator Programming Thread
Old 1 week ago
  #241
Gear Head
 

Quote:
Originally Posted by SkyWriter View Post
- I'll give lo-fi another listen, I might have broke it so I'll go back to the originals.
I don't think you broke it as I tried the LFO and EG using your M3 version...

Quote:
Originally Posted by SkyWriter View Post
- I meant I don't understand the rotary encoding -> waveform select logic. That's where the problem might be. I straightened out the row vs column stuff. But the encoding might be where the column mixup and the 5th row thing originates. Again, hard without a debugger. C++ is not my thing.
Ohhh, I understand now...

Quote:
Originally Posted by SkyWriter View Post
- :-) thank you for the waves!
My pleasure

Quote:
Originally Posted by SkyWriter View Post
Fwiw, I don't understand why my log stuff doesn't work. But it really doesn't work.
I wish I could help you with that...
Old 1 week ago
  #242
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
The other thing to consider is computational complexity; the delay requires nothing more than a r/w and point inc per sample, the FIR/IIR filter banks needs a lot more pointer math per sample. Also, the former is more suited to DRAM, while the latter would benefit from cache - data frequency models are polar opposites.
I ran into an issue with my SVF filter, and I think what you mention might be relevant.

The biquad filter examples Korg provided work in any FX slot -- mod, del, rev. But the SVF sounds *off* in the delay or reverb slots. The code in the Mod slot takes in the input *xn, processes it thru the filter, then spits it out to the functions output *yn.

Thing is, the Del and Rev process blocks don't have an output variable. The provided LFO and delay and Biquad examples simply reassign the processed output back onto the input xn.

The SVF filter *works*, but it sounds like half the signal is being passed without being processed, and doing filter and res sweeps affect only a second signal. It's like the Wet/Dry mix is set to 50/50. In addition, even the code is the same from the Mod slot, the range of the frequency is cut in half. And not only is the signal 50/50, but there's dirt on the signal too, maybe it's aliasing?

Guess I'll have to just keep experimenting.
Old 1 week ago
  #243
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
I ran into an issue with my SVF filter, and I think what you mention might be relevant.

The biquad filter examples Korg provided work in any FX slot -- mod, del, rev. But the SVF sounds *off* in the delay or reverb slots. The code in the Mod slot takes in the input *xn, processes it thru the filter, then spits it out to the functions output *yn.

Thing is, the Del and Rev process blocks don't have an output variable. The provided LFO and delay and Biquad examples simply reassign the processed output back onto the input xn.

The SVF filter *works*, but it sounds like half the signal is being passed without being processed, and doing filter and res sweeps affect only a second signal. It's like the Wet/Dry mix is set to 50/50. In addition, even the code is the same from the Mod slot, the range of the frequency is cut in half. And not only is the signal 50/50, but there's dirt on the signal too, maybe it's aliasing?

Guess I'll have to just keep experimenting.
Let's see.... do you have the param update for shift-shape done? It's part of del/rev now. If you didn't... then default behavior should be 50/50%. You want 100% wet.

Yeah, I saw the pointer assignments didn't make the same sense they did in the modfx. Figured It would make more sense when I got to that point.

Variable assignments between callbacks are pretty wacky when you try to extend synchronization beyond the periodic. Timing structures are ... hard to predict :-) I think I have it straightened out.

I cannot for the life of me figure out why log, log2 or log10 don't produce predictable results. I plot it out on a spreadsheet, use the same equations. No good. Idk, wrong math.h? I used the fast and faster too, still no good.
Old 1 week ago
  #244
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
Let's see.... do you have the param update for shift-shape done? It's part of del/rev now. If you didn't... then default behavior should be 50/50%. You want 100% wet.

Yeah, I saw the pointer assignments didn't make the same sense they did in the modfx. Figured It would make more sense when I got to that point.

Variable assignments between callbacks are pretty wacky when you try to extend synchronization beyond the periodic. Timing structures are ... hard to predict :-) I think I have it straightened out.

I cannot for the life of me figure out why log, log2 or log10 don't produce predictable results. I plot it out on a spreadsheet, use the same equations. No good. Idk, wrong math.h? I used the fast and faster too, still no good.
Thanks for the suggestion... added in the s_mix variable as seen in the Delayline sample code, but no effect.

Ah well, it might just be that this SVF algorithm doesn't jive with throwing its output back onto the input, as is required for the Del and Rev, unlike the Mod. The sample Biquad filters approach is different, using coefficients to calculate the poles and zeros. And even then, then the Mod Biquad just sets the filter process direct to the output, while the Del and Rev versions of the Biquad use multiply the filter process by 0.25 before sending it to the output... so there is some kind of difference between the Mod and the Del/Rev, like you noticed.

Apparently the Mod as an insert effect versus delay and reverb as send/return or dry/wet need to have slightly different processing code.

Ah well... will just need to keep hunting for more filter code.
Old 1 week ago
  #245
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
Ah well... will just need to keep hunting for more filter code.
Very interesting! Have a look at Oleg's effects code he did on NTS-1. They're built to run in any slot. They're not quite right for Prologue - too much CPU? But there might be a clue.
Old 1 week ago
  #246
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
Very interesting! Have a look at Oleg's effects code he did on NTS-1. They're built to run in any slot. They're not quite right for Prologue - too much CPU? But there might be a clue.
Great call! Oleg creates just one .cpp for each effect, but uses if statements to determine which FX slot it is being used in. The Mod FX do require a different treatment, primarily due to the fact that the Mod block processes input then sends to output, whereas the Del / Rev slots throw their stuff back onto the input, no separate output portion.

Code:
#ifdef FX_MODFX
    *(y++) = valp;
#else
    *x = valp;
#endif
#ifdef FX_MODFX_SUB
    valp = *x_sub;
Old 1 week ago
  #247
Lives for gear
 
SkyWriter's Avatar
So, we've seen this stuff before, but I laid it ALL out here anyway for the PROCESS callback. I see the input->output and main+sub as discussed. But where's left/right in this code? This stuff is heavy with implied use cases. Very cool to know!

REVFX:
Code:
 /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * Reverb effects must write back their result to the input buffer and are responsible for wet/dry mix balance.
   * Typically wet/dry balance should be controllable via the shift-depth parameter.
   *
   * param xn Input/output sample buffer. 
   * param frames Size of buffer in frames. (2 samples per frames)
   *
   * note Implementation must support at least up to 64 frames.
   * note Optimize for powers of two.
   */  
  void _hook_process(float *xn, uint32_t frames);
DELFX:
Code:
  /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * Delay effects must write back their result to the input buffer and are responsible for wet/dry mix balance.
   * Typically wet/dry balance should be controllable via the shift-depth parameter.
   *
   * param xn Input/output sample buffer. 
   * param frames Size of buffer in frames. (2 samples per frames)
   *
   * note Implementation must support at least up to 64 frames.
   * note Optimize for powers of two.
   */  
  void _hook_process(float *xn, uint32_t frames);
MODFX:
Code:
  /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * param main_xn Input sample buffer for main timbre
   * param main_yn Output sample buffer for main timbre
   * param sub_xn Input sample buffer for sub timbre
   * param sub_yn Output sample buffer for sub timbre
   * param frames Size of buffers. (2 samples per frames)
   *
   * note Implementation must support at least up to 64 frames.
   * note Optimize for powers of two.
   * note On platforms that do not have a sub timbre the sub_xn / sub_yn parameters can be ignored.
   */  
  void _hook_process(const float *main_xn, float *main_yn,
                     const float *sub_xn, float *sub_yn,
                     uint32_t frames);
note to self - remove at's before posting.
Old 1 week ago
  #248
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
So, we've seen this stuff before, but I laid it ALL out here anyway for the PROCESS callback. I see the input->output and main+sub as discussed. But where's left/right in this code? This stuff is heavy with implied use cases. Very cool to know!

REVFX:
Code:
 /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * Reverb effects must write back their result to the input buffer and are responsible for wet/dry mix balance.
   * Typically wet/dry balance should be controllable via the shift-depth parameter.
   *
   * @
para
m xn Input/output sample buffer. 
   * @
para
m frames Size of buffer in frames. (2 samples per frames)
   *
   * @
Note
 Implementation must support at least up to 64 frames.
   * @
Note
 Optimize for powers of two.
   */  
  void _hook_process(float *xn, uint32_t frames);
DELFX:
Code:
  /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * Delay effects must write back their result to the input buffer and are responsible for wet/dry mix balance.
   * Typically wet/dry balance should be controllable via the shift-depth parameter.
   *
   * @
para
m xn Input/output sample buffer. 
   * @
para
m frames Size of buffer in frames. (2 samples per frames)
   *
   * @
Note
 Implementation must support at least up to 64 frames.
   * @
Note
 Optimize for powers of two.
   */  
  void _hook_process(float *xn, uint32_t frames);
MODFX:
Code:
  /**
   * Processing callback. Must be implemented by your custom effect.
   *
   * @
para
m main_xn Input sample buffer for main timbre
   * @
para
m main_yn Output sample buffer for main timbre
   * @
para
m sub_xn Input sample buffer for sub timbre
   * @
para
m sub_yn Output sample buffer for sub timbre
   * @
para
m frames Size of buffers. (2 samples per frames)
   *
   * @
Note
 Implementation must support at least up to 64 frames.
   * @
Note
 Optimize for powers of two.
   * @
Note On
 platforms that do not have a sub timbre the sub_xn / sub_yn parameters can be ignored.
   */  
  void _hook_process(const float *main_xn, float *main_yn,
                     const float *sub_xn, float *sub_yn,
                     uint32_t frames);
Posting this suggests to me I should experiment with the buffer frame sizes, which I'd not considered as I saw that more as OSC stuff. Of course it makes sense now that I think about it, that it would affect *any* type of processing which involves digital sounds... so yeah....hehe.
Old 1 week ago
  #249
Lives for gear
@ Sky

I finally got around to auditioning more of your OSCs. Just had a blast experimenting with the Additive OSC with the EGs. There's a lot of variation that can be had in there.. from the Hammond thing beefing it up, to the Bumps thing adding or removing the crystalline characteristics, to selecting which Mod Target to have the EG affect... I liked Para 3.

I also had a blast with the Cain CZ osc. Besides the telltale phase distortion sonics, there's a lot of variation in there as well, with 21 waveforms and 14 EG types... some looping like LFOs, others looping unlike LFOs, pretty fresh-sounding modulations, esp when varying speed and amount.
Old 1 week ago
  #250
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
@ Sky

I finally got around to auditioning more of your OSCs. Just had a blast experimenting with the Additive OSC with the EGs. There's a lot of variation that can be had in there.. from the Hammond thing beefing it up, to the Bumps thing adding or removing the crystalline characteristics, to selecting which Mod Target to have the EG affect... I liked Para 3.

I also had a blast with the Cain CZ osc. Besides the telltale phase distortion sonics, there's a lot of variation in there as well, with 21 waveforms and 14 EG types... some looping like LFOs, others looping unlike LFOs, pretty fresh-sounding modulations, esp when varying speed and amount.
I love additive! I crank up all those little sine wave bumps, then use an app to measure stuff, like envelopes ;-) it's a great debug tool!
Attached Thumbnails
The Korg Logue User Oscillator Programming Thread-9eff71ab-98e0-43f2-b8e8-5ab3a9d7cadd.jpg  
Old 1 week ago
  #251
Lives for gear
Gotta say, Olev definitely is one very experienced programmer. His code is very logical and concise, and he handles juggling all those data types as easily as I type this. He's even written his own fxwrapper.h, so he only needs to write the source code once but use the header to suss out which slot is being used and therefore choose the proper Mod or Del/Rev code to use. Hopefully if I stare long enough at it it will soak into my brain via osmosis.

Old 1 week ago
  #252
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
I love additive! I crank up all those little sine wave bumps, then use an app to measure stuff, like envelopes ;-) it's a great debug tool!

Very interesting screenshot there. What is the app?

Wait what, measure *envelopes* you say? I've spent a couple hours searching the web for such a tool, as you know one of my strong contentions is that envelopes (on the macro as well as at the transient scale) are one of the strongest ways we recognize and distinguish sounds from one another. I mean, if you take a small melodic passage, and render it twice, once using MIDI and samples, another using a live player performing on an actual instrument, the difference in perception and quality is going to be down to the envelopes of those notes.
Old 1 week ago
  #253
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
Very interesting screenshot there. What is the app?

Wait what, measure *envelopes* you say? I've spent a couple hours searching the web for such a tool, as you know one of my strong contentions is that envelopes (on the macro as well as at the transient scale) are one of the strongest ways we recognize and distinguish sounds from one another. I mean, if you take a small melodic passage, and render it twice, once using MIDI and samples, another using a live player performing on an actual instrument, the difference in perception and quality is going to be down to the envelopes of those notes.
It's just a spectrograph*, with a couple of different color combinations. The vertical is a decade** frequency axis, and horz is a sliding time window. I use B&W - color blind. I set osc_add to lots of bumps. So when I sweep a shape - most prominent frequency, you get that cool outline on the spectrograph. Then I can measure the linearity*** vs log/exp results. Those are all linear plots of menu 5 with about a 1/2 second envelope. You have to get creative to see what's going on inside :-)

I need to check the cutoff and resonance input parameters. They would make great comparator input knobs.

I love that attack area, playing with VCA, Filter, and Oscillator attacks. You get so many colorations in just the psychoacoustic effects.

Got any small 'modem' codes? Hook a modem up to my mixer and use Kermit to read debug output from the oscillator.

*,**,***- interestingly, being log10 frequency and time, the plot is log/lin, but the lines are 'mostly linear'.

Last edited by SkyWriter; 1 week ago at 12:45 AM..
Old 1 week ago
  #254
Lives for gear
 
SkyWriter's Avatar
If you like spectrographs and osc_add, you'll like ANS. Same idea, different thing.

It's got some really crazy sounds. I would like to do something like that somehow. Another crazy oscillator roll-log has Shepard Tone generator - love it with tuned delays and other whirling effects.
Attached Thumbnails
The Korg Logue User Oscillator Programming Thread-69f25eb9-e9da-4932-842e-1c279d17ca3a.jpg  
Old 1 week ago
  #255
Lives for gear
 
SkyWriter's Avatar
Hey Psi, did you see my L+R question above effects? I don't see it... unless it's the +2 pointer thing?
Old 1 week ago
  #256
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
Hey Psi, did you see my L+R question above effects? I don't see it... unless it's the +2 pointer thing?
What was the question again? Not sure what you're referring to...
Old 1 week ago
  #257
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
What was the question again? Not sure what you're referring to...
In the PROCESS callback, the input and output buffers. What separates left and right for modfx and rev/delfx? Main and sub are identified, and effects have left and right information - where does come from, where does it go?
Old 1 week ago
  #258
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
In the PROCESS callback, the input and output buffers. What separates left and right for modfx and rev/delfx? Main and sub are identified, and effects have left and right information - where does come from, where does it go?
Ah gotcha. It's implicitly included... you run the output twice, once for left and right each. Example snippet from Hammond Eggs RandomLFO Filter tutorial, for ModFX slot only*:

Code:
void MODFX_PROCESS(const float *main_xn, float *main_yn,
                   const float *sub_xn,  float *sub_yn,
                   uint32_t frames)
{

const float * mx = main_xn;      
   float * __restrict my = main_yn;
   const float * my_e = my + 2*frames;

for (; my != my_e; ) 
   {
      *(sy++) = *(sx++);    // Copy *sy to *sx (Left channel)
      *(sy++) = *(sx++);    // Copy *sy to *sx again (right channel)

      // Get the input signal from the left channel (note effects are processed 
chorus->delay->reverb, and the synthesizer is currently mono up until the 
effects,
      //  so we'll just use the left channel input for now)
      
      sigIn = (*mx++);   
      mx++; // Advance the input pointer once more to skip the right channel input
                 // we're only using the left channel as an input in this demo.   

// Run the chamberlin filter (omitted here for clarity)
  
    // We'll use the L - lowpass output. Change this to H for highpass, N for 
    notch, and B for bandpass if you wish..
    
    sigOut = L;      
      
      // Send this out to the left channel      
      *(my++) = sigOut;
      // Send the same out to the right channel too, this is a mono effect.
      *(my++) = sigOut;      
   }

Ha! In answering your question, I think I just found the cause of my wonky filter issue... I hadn't noticed that the right channel was skipped in his sample code! Thanks, I think...

* for the Del / Rev slots, the input is mx, but once processed is also mapped back onto mx; there is no separate buffer variable for output.
Old 1 week ago
  #259
Lives for gear
Another way to put it below. The ModFX process block has both an input buffer and an output buffer, compared to the Del/Rev FX block that uses one buffer (*xn) as both input and output.


* `void MODFX_PROCESS(const float *main_xn, float *main_yn, const float *sub_xn, float *sub_yn, uint32_t frames)`

This is where you should process the input samples. This function is called every time a buffer of *frames* samples is required (1 sample per frame). *\*\_xn* buffers denote inputs and *\*\_yn* denote output buffers, where you should write your results.

.
.
.


* `void DELFX_PROCESS(float *xn, uint32_t frames)`

This is where you should process the input samples. This function is called every time a buffer of *frames* samples is required (1 sample per frame). In this case *xn* is both the input and output buffer. Your results should be written in place mixed with the appropriate amount of dry and wet signal (e.g.: set via the shift-depth parameter).
Old 1 week ago
  #260
Lives for gear
 
SkyWriter's Avatar
Ok got it Psi!, it's the +2 thing :-)
Old 6 days ago
  #261
Lives for gear
 
SkyWriter's Avatar
OK, time to stop screwing around and get started on the 3OP version.
Some notes:
1. As before the design is intended to provide a vehicle to evaluate modulation types and combinations. As such up to three new modulations, plus the LFO, are provided with 1-3 targets in combinations and alone - subject to limitations.
2. All possible combinations of inputs and modulation options can't be completely enumerated, so I've selected what I consider most useful - with helpful input from everyone. Sebo, I think I have your modulation type fairly well represented.
3. The spreadsheet elaborates the first hard coded input permutations in 1-30. The remaining are detailed in a matrix provided. The first three are just a shuffle as a good compromise between;
- every input gets the single complex modulation
- emphasis on the first two inputs for for most modulations
- while still getting the third one into the mix
the forth permutation is selected from a 2nd matrix of remaining possibilities. I selected one to fill out the rest of the menu. Although a 2nd set of oscillators could easily be generated with the remaining permutations if needed. These are test/eval vehicles.

The rest is the same as previous charts.
Available modulations:
- 3 stage ADS(R) (release derived from Decay as in M3 models)
- 2 stage AD, and KT
- two AD's
- one AD, and one LFO
- one AD, and two KT's
- one LFO and two KT's
- two LFO's
Also, the main LFO is available as a concurrent modulation source populating an additional modulator source in all combinations above.

PS: for the moment, I am going to punt implementing the lin/log stuff. Thinking about it, this is still a pretty rough cut at the code trying to push the envelope of expression, that much is accomplished merely having an EG. In terms of dynamics, there are a lot of moving parts now, picking out subtlety on one of three EG's is an opportunity cost I would rather recoup elsewhere in the code for CPU cycles.

PSS: as a matter of style, I like to go as far as I can before I have to backup and start addressing crafting. This is still just stepwise research for me. :-)
Attached Files
File Type: pdf M3O multimenu.pdf (99.5 KB, 4 views)

Last edited by SkyWriter; 6 days ago at 04:13 PM..
Old 6 days ago
  #262
Gear Head
 

Quote:
Originally Posted by SkyWriter View Post
OK, time to stop screwing around and get started on the 3OP version.
Some notes:
1. As before the design is intended to provide a vehicle to evaluate modulation types and combinations. As such up to three new modulations, plus the LFO, are provided with 1-3 targets in combinations and alone - subject to limitations.
2. All possible combinations of inputs and modulation options can't be completely enumerated, so I've selected what I consider most useful - with helpful input from everyone. Sebo, I think I have your modulation type fairly well represented.
3. The spreadsheet elaborates the first hard coded input permutations in 1-30. The remaining are detailed in a matrix provided. The first three are just a shuffle as a good compromise between;
- every input gets the single complex modulation
- emphasis on the first two inputs for for most modulations
- while still getting the third one into the mix
the forth permutation is selected from a 2nd matrix of remaining possibilities. I selected one to fill out the rest of the menu. Although a 2nd set of oscillators could easily be generated with the remaining permutations if needed. These are test/eval vehicles.

The rest is the same as previous charts.
Available modulations:
- 3 stage ADS(R) (release derived from Decay as in M3 models)
- 2 stage AD, and KT
- two AD's
- one AD, and one LFO
- one AD, and two KT's
- one LFO and two KT's
- two LFO's
Also, the main LFO is available as a concurrent modulation source populating an additional modulator source in all combinations above.

PS: for the moment, I am going to punt implementing the lin/log stuff. Thinking about it, this is still a pretty rough cut at the code trying to push the envelope of expression, that much is accomplished merely having an EG. In terms of dynamics, there are a lot of moving parts now, picking out subtlety on one of three EG's is an opportunity cost I would rather recoup elsewhere in the code for CPU cycles.

PSS: as a matter of style, I like to go as far as I can before I have to backup and start addressing crafting. This is still just stepwise research for me. :-)
It is looking great!!! I'm very exited to try the final version

Just one note:
I just realized that Attack only EG is the same as an inverted Decay only EG...
Unless I'm missing somenthing, could be omitted.
Old 6 days ago
  #263
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by Sebo Synths View Post
It is looking great!!! I'm very exited to try the final version

Just one note:
I just realized that Attack only EG is the same as an inverted Decay only EG...
Unless I'm missing somenthing, could be omitted.
Yeah, been thinking about that, it is, and it isn't. It's a usability* thing to experiment with. I kept going back and forth on it. But here's the rational; The Attack goes from input bias (whatever you have the static control for that input set to) to +/- intensity, then to bias again. Decay, goes from +/- intensity to bias. If I add a hook to hang the attack at the top, then they're both technically Ramp's I guess, but still opposite start and end points. But the real difference was when attack was log and decay was exp. So, at this point, it's kind of vague. Work in progress :-)

I could make them both attacks with the hang? Call them RTZ Ramp's.

I've been playing a lot with the EG * LFO options, really cool sounds when you use a Ramp of Sqr LFO with an EG, even FAST is somewhat useful in the low-mid range with a long attack to give it a delay growl. I keep spending hours playing and voicing instead of coding - and that's the danger of functional prototypes - they become 'good enough' to distract you quickly. I've been really working mM3_add lately. You can get those plucky mid-resonance tones without chopping the entire top end off, going either into, or in parallel with the analog side with an opposite, or longer filter contour, to get two dynamic filters active per voice. It's just so much difference to play with now. Can't wait to get KT's in there with LFO and EG.

I love KT's, they can make sound into an instrument.

*-I like to think of center points and offsets. Although, they may map into the same space equally, one starts and ends in order, the other you do backwards. The other thing is thinking always in terms of programming left to right. If you always have to set the second one first then adjust with the first one, you're going to bang the button a lot. However, if you can program in the same order, it goes faster.

For instance:
Rate then Intensity. That's backwards. It should be Intensity, then Rate. You want every button push to bring you closer to not pushing the button again. If I have Rate then Intensity, I'm always going to do this;
1. blindly crank a rate up from zero,
2. set an expected Intensity, and discover what the Rate is
3. Bang on around back to Rate.
4. Set the Rate to what I really wanted.
5. Now set the Intensity where I expect it to be.
Instead it should be:
1. Set the Intensity to where I want the limits to be. Done.
2. Set the Rate appropriate for the Rate. Done
3. On to next setting
So, plenty of things to think about still.

Last edited by SkyWriter; 6 days ago at 09:08 PM..
Old 6 days ago
  #264
Lives for gear
 
SkyWriter's Avatar
If there was a simple way to get data out of an oscillator, I would love to program an oscillator interface that just used a 0-100 index on the menu, and the shape Knob.

Then to program, all you have to do is turn the Value entry knob to select your parameter, and the shape knob to set the value. It would go REAL fast to do oscillator changes on the instrument. Once you got the sound you want, hit a tri-tone three times, and the oscillator(s) dump all the program parameters.
Old 6 days ago
  #265
Lives for gear
Tritone!

Old 6 days ago
  #266
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by psionic11 View Post
Tritone!

LOL! :-)
Old 6 days ago
  #267
Lives for gear
Quote:
Originally Posted by SkyWriter View Post
OK, time to stop screwing around and get started on the 3OP version.
Some notes:
Are ME1-6 menu entries? Can those be changed through the six NRPNs instead, with an external MIDI controller? I'm still not clear what those are for.
Old 6 days ago
  #268
Lives for gear
Quote:
Originally Posted by AndyHornBlower View Post
Are ME1-6 menu entries? Can those be changed through the six NRPNs instead, with an external MIDI controller? I'm still not clear what those are for.
That's a good question, and I tried doing just that a couple days ago. I had gotten those MIDI CC values I posted earlier by watching corresponding changes via a MIDI monitor. But playing them back did not result in my XD updating its values.

Seems I need to better understand how Korg is implementing NRPN.

The problem may be that I was sending individual CC 98 values, then individual CC 6 values using 2 knobs from the Kronos in external MIDI controller mode. It might be that the MIDI spec requires CC 98 and 6 to be sent immediately sequentially.... one compound message versus two sequential messages...
Old 6 days ago
  #269
Lives for gear
 
SkyWriter's Avatar
Quote:
Originally Posted by AndyHornBlower View Post
Are ME1-6 menu entries?
Yes. I copied what I considered de-facto nomenclature to describe the implied behavior of it all in logue's context. If you used Roll-log's Scan, Fume, or Syng, then you would recognized their 'cheat sheet' style. It's a common multiplexor scheme for logic designers.

Quote:
Can those be changed through the six NRPNs instead, with an external MIDI controller? I'm still not clear what those are for.
I haven't tried, but if they do I've got an engineering notebook full of ideas for it. If it doesn't, I guess I'll grind a different axe :-)

Who's got the assembly code effort? :0)
Old 6 days ago
  #270
Lives for gear
Quote:
Originally Posted by psionic11 View Post
I had gotten those MIDI CC values I posted earlier by watching corresponding changes via a MIDI monitor. But playing them back did not result in my XD updating its values.

Seems I need to better understand how Korg is implementing NRPN.
The "leaving out CC 98 for clarity" part is throwing me a little - I'd rather see the whole of each message. I'll have a look at it tomorrow.

The main thing is, I don't really know what I'm aiming for. Does the XD have those controls, or is that just a Prologue thing? If not, maybe it responds to the right message, but I might have no way of generating it.

Also, I don't really understand what those controls should be controlling.

I do have MIDI controllers that can send either NRPN MSB or NRPN LSB. If I understand that correctly, that's a three byte message, but it might use "Running status" if I send a stream of values from the same knob - i.e. only send the part of the message that's changed.

The Wiki page refers to MSB and LSB, but that seems to be to specify the NRPN parameter number. It says:

https://en.wikipedia.org/wiki/NRPN

"First, controller 99 - NRPN Most Significant Byte (MSB) - followed by 98 - NRPN Least Significant Byte (LSB) sent as a pair specify the parameter to be changed. Controller 6 then sets the value of the relevant parameter. Controller 38 may optionally then be sent as a fine adjustment to the value set by controller 6."

I take that to mean a two byte message to specify which NRPN, as CC99 then CC98, followed by CC6 for the MSB of the value, with CC38 if needed to specify the LSB - but I'm guessing the controllers I have can omit CC6 to send just the LSB with CC99 CC98 CC38 (38= 6+32 for the fine value, which they call NRPN LSB, meaning the LSB of the data value, not the parameter number).

So, maybe if I use that sort of MIDI controller to send what it calls "NRPN MSB", it sends CC99 CC98 CC6 - and perhaps the XD will just ignore the CC99. If it needs the CC63 at the end as part of the message though, it's not going to work.

It would help if I knew what I should expect it to do, before I start
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump