o.strandem
Max Output Level: -90 dBFS
- Total Posts : 12
- Joined: 2004/03/27 09:17:19
- Status: offline
Midi filter on live input
Hi, I'm trying to use my laptop running sonar to control several softsynths at the same time, but I'm having trouble specifying the keyranges for the different synths so I can control them all from a single midikeyboard. I tried using the CakewalkFx Midi Event filter to single out the keyranges i wanted the synth to respond to, but it wouldnt work on realtime input, only recorded mididata. Does anone know about some kind of keyrangefilter that responds to realtime midi input? Or does anyone know how to make one?
Thanks,
Oyvind Strandem
|
Markleford
Max Output Level: -87 dBFS
- Total Posts : 173
- Joined: 2003/11/11 10:24:11
- Location: The Beach, FL
- Status: offline
RE: Midi filter on live input
2004/03/27 15:37:16
(permalink)
Should be very easy to do in MFX. What exactly are you looking to do?
- m
|
o.strandem
Max Output Level: -90 dBFS
- Total Posts : 12
- Joined: 2004/03/27 09:17:19
- Status: offline
RE: Midi filter on live input
2004/03/27 18:51:00
(permalink)
What I basically want to do, is to be able to connect a single midikeyboard to my laptop running sonar. This keyboard will send on all channels. Then, within sonar I would like to be able to separate the midi-information coming in and then route that to different synths.
So for example: I can route all mididata within one octave of channel 3 to one softsynth, and all mididata within two octaves of channel 12 to a diferent softsynth. So something like the midi event filter mfx in sonar 3 could work if it had a bit more options and would work on real-time input.
Thanks,
Oyvind Strandem
|
mbncp
Max Output Level: -83 dBFS
- Total Posts : 396
- Joined: 2003/12/14 19:06:44
- Status: offline
RE: Midi filter on live input
2004/03/27 20:44:54
(permalink)
Hi O, there are (at least) 4 ways to do this way 1) the easy one use cubase sx, you can use up to 4 midifx as sends and the transformer midi plug to do the filtering  way 2) the less easy one you need to create two different plugs a) first plug in OnInput(..) convert the MfxData type to an MfxEvent of type ShortMsg then send the event(s) using OnEvent from the IMfxInputCallback interface NOTE: be aware that IMfxInputCallback is a bit buggy... b) second plug create a 'simple' plug that will just filter your input MfxData to your will, pitch, channel, etc.. now: 1) make sure Option\Global\Midi\Echo DXi input to all midi tracks IS CHECKED 2) On the track where you have your keyboard as input, insert the first plug 3) on the other tracks, insert the second plug, and set the filtering you want for each output (dxi or vsti synth, ext midi,..) 4) make sure that the first track (with plug a) has midi echo enabled 5) for all other track that you want to hear the synth at the 'same time', enable midi echo as well (red or green -)) symbol) This will not work on track events, you will have to record while playing on the keyboard. Well you could also make plug 'a' a 'master', and b working as 'slaves', and send the data to the other plugs (internally), and these would do the filtering in OnEvents (tracks). In this case it would be easier if plug a and b are the same plug. Use a static array or list to keep track of all your plug instances. ok, this one was a joke  too .. way 3) the logical one Create an mfx midi pluging that will just do the filtering in OnInput and OnEvents (see the sdk for how to pass, modify and delete events). Insert an instance of the plug in each track where you have a synth you want to hear. Make sure to set the midi input of all these tracks to the input port of your external keyboard and click the echo enable button on them. Note that you don't have to do the channel filtering in the plugin, as you can define which input channel you want on each track. way 4) the universal one If you want to have a single window where you define your settings, create a plug as a standard windows app, with midi in and midi out. set midi in to your synth, do the filtering and send the midi data to a virtual midi port like midiyoke, and connect each port in sonar with the appropriate midiyoke in ports. way 5) the unsupported one if we could define an ouput port in OnInput/Onevents, we could have a single plug on a single track, sending the different events to the appropiate tracks/ouputs. But sonar/mfx can't do that so ... best of luck 
< Message edited by mbncp -- 3/27/2004 8:57:49 PM >
|
o.strandem
Max Output Level: -90 dBFS
- Total Posts : 12
- Joined: 2004/03/27 09:17:19
- Status: offline
RE: Midi filter on live input
2004/03/28 09:27:03
(permalink)
Thanks alot for helping. I reckon number 3 is the way to go. But..... I'm no developer, I have more or less no clue how to make such a plugin... Anyone up for a challenge??  Or alternatively if you could guide me on how to do it... ?? Thanks again!
|
Markleford
Max Output Level: -87 dBFS
- Total Posts : 173
- Joined: 2003/11/11 10:24:11
- Location: The Beach, FL
- Status: offline
RE: Midi filter on live input
2004/03/29 10:27:01
(permalink)
ORIGINAL: o.strandem
Thanks alot for helping. I reckon number 3 is the way to go. But..... I'm no developer, I have more or less no clue how to make such a plugin... Anyone up for a challenge?? I was going to propose a "#3" solution, myself (it's pretty much my idiom for MFX plugs: Marc's methods are light-years beyond what I do! :) ) Just need a bit of time: I'm trying to line up a new job now, so I'm a bit distracted... - m
|
Markleford
Max Output Level: -87 dBFS
- Total Posts : 173
- Joined: 2003/11/11 10:24:11
- Location: The Beach, FL
- Status: offline
RE: Midi filter on live input
2004/03/31 12:22:26
(permalink)
Oyvind: I found some time to code! Go to my site and try out my new TenCrazy.com MFX Track Doorman. Right now it only does the most minimal checking: keyrange! We'll add features to it later as you need them. Have fun, - m
|
jhonvargas
Max Output Level: -83 dBFS
- Total Posts : 371
- Joined: 2003/11/06 07:34:55
- Location: Australia
- Status: offline
RE: Midi filter on live input
2004/03/31 14:07:20
(permalink)
Hey,
I started coding my own MFXs (thanks -m for your valuable help) and got some questions:
My MFX plugin is similar to -m's PW Mapper but allows me to map not only the pw but any other controller. So I make some processing in the OnEvents method. It is required that the plugin work for live input data too so. My question is: How can I convert the IMfxDataQueue* parameter in the OnInput method to an IMfxEventQueue*?? This is because I coded a "ProcessQueue"
ProcessQueue(IMfxEventQueue* pqIn, IMfxEventQueue* pqOut )
method that is intended to process both data from live input (OnInput) and data from the track (OnEvents). At this time I can call this method from OnEvents but not from the OnInput since the parameters are of different type.
Should I have to make the whole code for the OnInput too?? (it will be quite ridiculous!!!) Thanks for your help...
|
mbncp
Max Output Level: -83 dBFS
- Total Posts : 396
- Joined: 2003/12/14 19:06:44
- Status: offline
RE: Midi filter on live input
2004/03/31 14:51:39
(permalink)
Hi John, Yes OnIput(live data) has MfxData type and the buffers are IMfxDataQueue, and OnEvents(track data), as well as OnStart, OnStop and OnLoop have MfxEvent types and IMfxEventQueue buffers. What I did in MfxScript was to make the user using all functions with the same data type, and to make it faster I just use arrays of longs (this is not exactly true as text, lyrics and sysex are 'strings', but with vbscript this is transparent to the user). OnInput can handle only short midi message (no sysex), and of course it does not have note length. If you want to do your own buffering, with a single buffer type, convert MfxData to MfxEvent type and use a IMfxEventQueue in both case, using a single function. Make sure, that when you send live events to convert back to MfxData, and create two events for note on note off. If you are using RPN, NRPN make sure to create the extra CC events as well. I agree that this is a beat 'cheap' on the side of the SDK, and that we should have single event types, and that the SDK should handle the conversion. Be aware, that in OnEvents, not to 'overflow' the 'lTimeThru' timestamp, it will work with external midi devices, but not with sofsynths. Again in MfxScript, this is transparent as I create my own buffers to handle that, and they are destroyed automatically, in OnStop, OnLoop. As I recall, there is also a bug when calling certain event types in OnStart, so I start the buffering there, and I send them at the right moment in OnEvents.
< Message edited by mbncp -- 3/31/2004 2:52:42 PM >
|
Markleford
Max Output Level: -87 dBFS
- Total Posts : 173
- Joined: 2003/11/11 10:24:11
- Location: The Beach, FL
- Status: offline
RE: Midi filter on live input
2004/03/31 14:51:51
(permalink)
ORIGINAL: jhonvargas
Should I have to make the whole code for the OnInput too?? (it will be quite ridiculous!!!) Unfortunately, that's typically what one has to do! Moreover, OnInput() code is even more difficult to write than OnEvent(), as you have to track both MIDI Note On and Note Off messages (with no access to a 'duration' field) due to its live nature. Luckily you won't have to deal with that if you're just doing controllers, but you will have to "parse" the MIDI messages by hand, as they're not put into a tidy struct/union! So welcome to the wild world of MFX programming! Hopefully you'll find it worth the effort. ;) - m
|
jhonvargas
Max Output Level: -83 dBFS
- Total Posts : 371
- Joined: 2003/11/06 07:34:55
- Location: Australia
- Status: offline
RE: Midi filter on live input
2004/03/31 15:14:58
(permalink)
Hey,
Thanks you both.
So I am planning to do the following:
- Define a MfxEvent variable
- Parse the MfxData m_dwData member
- Populate the MfxEvent with the "sub-members" (bytes) resulting from the parsing of m_dwData
- Process the MfxEvent similarily as in the OnEvents method
- Take the processed MfxEvent and chain some of its members for updating the MfxData
- Add the MfxData to the out queue
Is this OK??
By the way, where can I find information about the ShortMsg format in order to be able to parse it appropiately???
Thanks guys,
John
|
mbncp
Max Output Level: -83 dBFS
- Total Posts : 396
- Joined: 2003/12/14 19:06:44
- Status: offline
RE: Midi filter on live input
2004/03/31 15:30:10
(permalink)
hi john, don't use m_dwData, use m_byStatus, m_byData1 and m_byData2 this is just standard midi check this site for great midi info http://www.borg.com/~jglatt/tech/miditech.htm it shows you also how to map 14 bit data (pitch wheel) to real numbers
|
mbncp
Max Output Level: -83 dBFS
- Total Posts : 396
- Joined: 2003/12/14 19:06:44
- Status: offline
RE: Midi filter on live input
2004/03/31 15:44:05
(permalink)
with a litlle help ... MfxScript is going open source ... from MfxData to array of long int MfxPlug::MfxDataToArray(MfxData &data, long *p)
{
p[evTIME] = data.m_lTime;
switch(data.m_byStatus & 0xF0)
{
case 0x90:
if(data.m_byData2 != 0)
{
p[evTYPE] = eNOTE;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[noteKEY] = data.m_byData1;
p[noteVELOCITY] = data.m_byData2;
break;
}
case 0x80:
p[evTYPE] = eNOTE;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[noteKEY] = data.m_byData1;
p[noteVELOCITY] = 0;
p[noteVELOFF] = data.m_byData2;
break;
case 0xA0:
p[evTYPE] = eKEYAFT;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[keyaftKEY] = data.m_byData1;
p[keyaftAMOUNT] = data.m_byData2;
break;
case 0xB0:
p[evTYPE] = eCONTROL;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[controlCC] = data.m_byData1;
p[controlVALUE] = data.m_byData2;
break;
case 0xC0:
p[evTYPE] = ePATCH;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[patchPATCH] = data.m_byData1;
p[patchBANKSELMETHOD] = -1; //todo ?
p[patchBANK] = -1; //todo ?
break;
case 0xD0:
p[evTYPE] = eCHANAFT;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[chanaftAMOUNT] = data.m_byData1;
break;
case 0xE0:
p[evTYPE] = eWHEEL;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[wheelVALUE] = (data.m_byData1 | (data.m_byData2 << 7)) - 8192;
break;
default:
p[evTYPE] = eSHORTMSG;
p[evCHANNEL] = data.m_byStatus & 0x0F;
p[shortmsgMIDI] = data.m_dwData;
break;
}
return S_OK;
} Then from array to MfxEvent int MfxPlug::ArrayToMfxEvent(long *p, MfxEvent &event)
{
event.m_eType = (MfxEvent::Type)p[evTYPE];
event.m_lTime = p[evTIME];
switch(p[evTYPE])
{
case eNOTE:
event.m_eType = MfxEvent::Note;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_byKey = p[noteKEY];
event.m_byVel = p[noteVELOCITY];
event.m_byVelOff = p[noteVELOFF];
event.m_dwDuration = p[noteDURATION];
break;
case eKEYAFT:
event.m_eType = MfxEvent::KeyAft;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_byKey = p[keyaftKEY];
event.m_byAmt = p[keyaftAMOUNT];
break;
case eCONTROL:
event.m_eType = MfxEvent::Control;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_byNum = p[controlCC];
event.m_byVal = p[controlVALUE];
break;
case ePATCH:
event.m_eType = MfxEvent::Patch;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_byPatch = p[patchPATCH];
event.m_byBankSelMethod = p[patchBANKSELMETHOD];
event.m_nBank = p[patchBANK];
break;
case eCHANAFT:
event.m_eType = MfxEvent::ChanAft;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_byAmt = p[chanaftAMOUNT];
break;
case eWHEEL:
event.m_eType = MfxEvent::Wheel;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_nVal = p[wheelVALUE];
break;
#ifndef FREEWARE
case eRPN:
event.m_eType = MfxEvent::RPN;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_wNum = p[rpnNUMBER];
event.m_wVal = p[rpnVALUE];
break;
case eNRPN:
event.m_eType = MfxEvent::NRPN;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_wNum = p[nrpnNUMBER];
event.m_wVal = p[nrpnVALUE];
break;
case eSYSX:
event.m_eType = MfxEvent::Sysx;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_hBuffer = (MFX_HBUFFER)p[sysxBUFFER];
break;
case eTEXT:
event.m_eType = MfxEvent::Text;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_hBuffer = (MFX_HBUFFER)p[textBUFFER];
break;
case eLYRIC:
event.m_eType = MfxEvent::Lyric;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_hBuffer = (MFX_HBUFFER)p[lyricBUFFER];
break;
case eMUTEMASK:
event.m_eType = MfxEvent::MuteMask;
event.m_maskSet = p[mutemaskMASKSET];
event.m_maskClear = p[mutemaskMASKCLEAR];
event.m_mfxChannel = p[mutemaskMFXCHANNEL];
break;
case eVELOFS:
event.m_eType = MfxEvent::VelOfs;
event.m_nOfs = p[velofsOFS];
event.m_mfxChannel = p[velofsMFXCHANNEL];
break;
case eVELTRIM:
event.m_eType = MfxEvent::VelTrim;
event.m_nTrim = p[veltrimTRIM];
event.m_mfxChannel = p[veltrimMFXCHANNEL];
break;
case eKEYOFS:
event.m_eType = MfxEvent::KeyOfs;
event.m_nOfs = p[keyofsOFS];
event.m_mfxChannel = p[keyofsMFXCHANNEL];
break;
case eKEYTRIM:
event.m_eType = MfxEvent::KeyTrim;
event.m_nTrim = p[keytrimTRIM];
event.m_mfxChannel = p[keytrimMFXCHANNEL];
break;
case eSHORTMSG:
event.m_eType = MfxEvent::ShortMsg;
event.m_byPort = p[evPORT];
event.m_byChan = p[evCHANNEL];
event.m_dwShortMsg = p[shortmsgMIDI];
break;
#endif //FREEWARE
default:
return -1;
}
return S_OK;
}
and now the constants: #define eNOTE 0x0001
#define eKEYAFT 0x0002
#define eCONTROL 0x0004
#define ePATCH 0x0008
#define eCHANAFT 0x0010
#define eWHEEL 0x0020
#define eRPN 0x0040
#define eNRPN 0x0080
#define eSYSX 0x0100
#define eTEXT 0x0200
#define eLYRIC 0x0400
#define eMUTEMASK 0x0800
#define eVELOFS 0x1000
#define eVELTRIM 0x2000
#define eKEYOFS 0x4000
#define eKEYTRIM 0x8000
#define eSHORTMSG 0x10000
#define eUSER 0x1000000 //2^24
#define evTYPE 0
#define evTIME 1
#define evPORT 2
#define evCHANNEL 3
#define noteKEY 4
#define noteVELOCITY 5
#define noteVELOFF 6
#define noteDURATION 7
#define keyaftKEY 4
#define keyaftAMOUNT 5
#define controlCC 4
#define controlVALUE 5
#define patchPATCH 4
#define patchBANKSELMETHOD 5
#define patchBANK 6
#define chanaftAMOUNT 5
#define wheelVALUE 5
#define rpnNUMBER 4
#define rpnVALUE 5
#define nrpnNUMBER 4
#define nrpnVALUE 5
#define sysxBUFFER 7
#define textBUFFER 7
#define lyricBUFFER 7
#define mutemaskMASKSET 5
#define mutemaskMASKCLEAR 6
#define mutemaskMFXCHANNEL 7
#define velofsOFS 5
#define velofsMFXCHANNEL 7
#define veltrimTRIM 6
#define veltrimMFXCHANNEL 7
#define keyofsOFS 5
#define keyofsMFXCHANNEL 7
#define keytrimTRIM 6
#define keytrimMFXCHANNEL 7
#define shortmsgMIDI 7
and thanks to report any bug  well, you still have some work todo, merge the functions and create a single one, but this should make it a bit easier
|
Markleford
Max Output Level: -87 dBFS
- Total Posts : 173
- Joined: 2003/11/11 10:24:11
- Location: The Beach, FL
- Status: offline
RE: Midi filter on live input
2004/04/02 18:22:02
(permalink)
I've taken a look at this new event typing system with some interest. Do you think it would be worth trying to get the whole "MFX community" on-board with such an architecture? And could it be made even more portable, such as to leverage algorithms on as many hosts as possible with fewer special-purpose code changes?
- m
|
mbncp
Max Output Level: -83 dBFS
- Total Posts : 396
- Joined: 2003/12/14 19:06:44
- Status: offline
RE: Midi filter on live input
2004/04/03 12:34:47
(permalink)
hmm ... not an easy task steinberg uses the midi spec as for the types // from the vst module architecture SDK // MidiStatus table
//------------------------------------------------------------------------
enum MidiStatus
{
//------------------------------------------------------------------------
kNoteOff = 0x80, // note, off velocity
kNoteOn = 0x90, // note, on velocity
kPolyPressure = 0xA0, // note, pressure
kController = 0xB0, // controller, value
kProgramChange = 0xC0, // program
kAfterTouch = 0xD0, // pressure
kPitchBend = 0xE0, // lsb, msb
kSysexStart = 0xF0, // data byte until sysexend
kQuarterFrame = 0xF1, // quarter frame message
kSongPointer = 0xF2, // msb, lsb
kSongSelect = 0xF3, // number
kCableSelect = 0xF5, // cable
kSysexEnd = 0xF7, //
kMidiClock = 0xF8, //
kMidiClockStart = 0xFA, //
kMidiClockContinue = 0xFB, //
kMidiClockStop = 0xFC, //
kActiveSensing = 0xFE, //
kMidiReset = 0xFF //
//------------------------------------------------------------------------
}
// Event manipulation
//------------------------------------------------------------------------
virtual tresult PLUGIN_API setStart (IMEObjectID event, long ppq) = 0;
virtual long PLUGIN_API getStart (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setLength (IMEObjectID event, long ppq) = 0;
virtual long PLUGIN_API getLength (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setImmediateEvent (IMEObjectID event, bool state) = 0;
virtual bool PLUGIN_API isImmediateEvent (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setChannel (IMEObjectID event, int channel) = 0;
virtual int PLUGIN_API getChannel (IMEObjectID event) = 0;
virtual MidiStatus PLUGIN_API getStatus (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setStatus (IMEObjectID event, MidiStatus status) = 0;
virtual int PLUGIN_API getData1 (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setData1 (IMEObjectID event, int data) = 0;
virtual int PLUGIN_API getData2 (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setData2 (IMEObjectID event, int data) = 0;
virtual int PLUGIN_API getData3 (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setData3 (IMEObjectID event, int data) = 0;
virtual int PLUGIN_API getMicroTuning (IMEObjectID event) = 0;
virtual tresult PLUGIN_API setMicroTuning (IMEObjectID event, int cent) = 0;
here we have an extra param for notes (micro tuning) and we can get/set isImmediateEvent (Live or Track), but the RPN, Text, Lyrics are cakewalk only it's a bit dumb as cubase has text support, as well as the meta events, would be nice to have them, but... at least they use the same format for live and track events I haven’t been too much into the yamaha sdk, but I expect some more variations. www.midi.org tries to create some standards ... well The worst of the midi spec is all the multiple events, like the rpn, nrpn, bank, patch change... Cakewalk did a pretty good job by creating single events, this should be enhanced and become a standard. The best one is the pitch wheel, here we really should have a float/double type or a highword/loword long value. So when you write 22.250 you get a 25 notes + ¼ note pitch wheel value, no need to call RPN+pw or cc+cc+cc+cc+pw. There could be some probs. with external midi devices (espc. Old ones) but the host should provide some settings and deal with that. Now with soft synth, this is not an issue anymore. As a midi plug is the centre piece it’s should also get more info from the host and from the connected dxi/vsti. (track name, plug routing, other tracks info …, synth name, key names, patch names, routing,…) Btw, I did some test on project5, and the mfx implementation looks a better than under S3, you can check this post: http://www.cakewalk.com/forum/tm.asp?m=94424 Anyway, I was playing a bit with the synchron 32 mfx plug, and got a bit depressed, so it’s time for us to write this great pattern sequencer ( I will make a new post soon (mfx forum), so make sure visual c++ is loaded) [sm=rolleyes.gif]
|
SergeD
Max Output Level: -88 dBFS
- Total Posts : 149
- Joined: 2004/06/07 22:29:56
- Status: offline
Re: RE: Midi filter on live input
2009/10/04 22:57:57
(permalink)
mbncp,
Anywhere you are 5 years later thank you for your MfxData to MfxEvent conversion tips. I will try this and hope that my problem will be resolved !
SergeD
|