# Using more than 16 channels in K2 and allowing aftertouch and sysex



## mbncp (Jul 3, 2007)

EDIT:
I'm currently working on a vst-midi plug and it's associated ksp script.
The plug (vst-midi) converts any message to 3 special _note on_ events.
The KSP script converts back these special notes to their original meaning.

This allows to receive any MIDI event, including aftertouch, patch change (optional) and sysex in KSP.
Port and channel information is included which allows to have extra virtual channels, and the included channel info can be used to trigger different groups within a single instrument.

*EDIT: I abandon the project, as it uses far too many resources in K2.*


Cheers,
Marc


----------



## Big Bob (Jul 5, 2007)

Hey Marc,

When you get this all tied up in a pink ribbon do you plan to donate it to the K2 community or is this going to be commercial?

I'm still trying to decide the best slot 1 script function for SIPS. I kind of envisioned some kind of articulation switching and/or other general pre-processing. But, an extended version of what you are cooking up here might be just what the Doctor ordered :D . The channelizing plus the mapping of now-missing Aftertouch, etc makes this sound quite interesting. For example, the ability to assign the SVS Vib-Amt CC to Aftertouch would be nice. 

Also, for my latest version of the ISCS (which supports nested subroutine calling), we need a 'Starter Script' in slot 1 to get the circus going. The needs of the starter script are miniscule, so it would be nice to combine it with another script that provides other useful functions. Please keep us posted as to your progress on this.

God Bless,

Bob


----------



## mbncp (Jul 5, 2007)

Hi Bob,

It will be free and open source, but coffee and aspirin donations are accepted :wink: 

I agree, a general slot1 having some helpers is a good idea. As an example, this port stuff can be disabled using a single *if* statement, as everything is contained in the _on note_ callback.

Btw, to send channel info and note off velocity I'm using set_event_par ( a single index ). Is there currently one index that is used as a specific meaning by some of you ?

Thanks,
Marc


----------



## Big Bob (Jul 5, 2007)

> It will be free and open source ..



Hey that's super Marc :D 



> Btw, to send channel info and note off velocity I'm using set_event_par ( a single index ). Is there currently one index that is used as a specific meaning by some of you ?



That's a good question and the answer is yes and no :wink: . When I first wrote the ISCS (InterScript Communication System), I more or less started cooking up a set of conventions that I've been kicking around a little bit with Nils. However, since he's gotten so busy we haven't had much chance yet to put these conventions to an acid test. The ISCS itself, uses all 4 EPs but only with it's Messenger Note (usually note 0). The ISCS uses EP3 for a 4-field descriptor and the remaining 3 EPs for passing interscript data back and forth and for passing intrascript subroutine parameters.

However, for the general note traffic (ie other than note 0), the only convention nailed down so far is that EP3 is always used for ID tagging (so scripts farther on down the line can know which preceding script generated or manipulated the note). Other than that, there has only been a little banter about what kind of info to carry in the other 3 EPs (such as tuning, volume, panning, etc). However, nothing has been nailed down. I have however pretty well concluded that for the most part, all tuning, volume, and panning performed by a cascaded script should be done incrementally (relative to the last change). We've already been doing that for volume manipulations because we were forced into it (since the absolute mode doesn't work properly). But, so far, a lot of scripts were written to use absolute pitch tuning (including some of my earlier work). I have slowly been changing my stuff over to all incremental control. 

The convention now is to set the lowest 11 bits of EP3 to a unique Script ID code (assigned to each script author by me I guess :? ). So, if you can get by with the remaining 21-bits, then using EP3 should work out. If you need more than 21 bits, then I suggest you use an EP other than 3. Perhaps, before you cast this in concrete, you could run it by me (since right now I seem to be the central clearing house for discussions on making scripts play together in a friendly way :lol .

If you are interested in looking over the current version of the ISCS, send me a PM and I'll email a copy to you. 



> I agree, a general slot1 having some helpers is a good idea. As an example, this port stuff can be disabled using a single if statement, as everything is contained in the on note callback.



It would also be nice if we could arrange it so the script (in slot 1) could tell when the plugin is active or not. When the plug is missing or inactive, the script could just pass MIDI data unaltered (for the most part). That way, if other features are added to this 'front-end' script, they could be utilized with or without the active presence of the plug. The 'front-end' script could also relay it's status to the remaining scripts using the ISCS Omni-Message facility.



> .. but coffee and aspirin donations are accepted



No problemo, since I have now fully restocked my supply :wink:

God Bless,

Bob


----------



## mbncp (Jul 6, 2007)

Hi Bob,



> The convention now is to set the lowest 11 bits of EP3 to a unique Script ID code


Just an idea, wouldn't it be better to use flags instead of a script ID ?

A specific flag(s) could mean that EP0 contains tuning info, which makes this info available to all slots.

Btw, in my case I need 11 bits. 7 for note_off velocity (0-127) which is generated just before calling note_off(ev_id) and 4 bits for the channel info (0-15).
But then it could be nice to have 2 extra ones to differentiate from value = 0 or value is not set.



> It would also be nice if we could arrange it so the script (in slot 1) could tell when the plugin is active or not.


That's a little the tricky part.
Currently, in auto mode, using only 4 ports, I need 11 keys (key 0 to key 11, or C-2 to B-2) to pass the encoded events, so when I detect these events I try to decode them, if a higher pitch is received, I exit the callback.
Other callbacks are not handled so there isn't a problem on this side.

When the vst plug is enabled (a port is selected) it sends only note on events in that specific range.

I could also implement a watch dog, the plug sending some CC every 5 seconds or so, but this could make things a bit complicated. 
If a user really needs C-2 to B-2, it's always possible to set the script to manual mode (on or off).

The main problem is that I really have to turn off these events (note_on generated by the plug) or the voice buffer will grow to eventually reach the 8192 events limit, which is a bit annoying 

Cheers,
Marc


----------



## Big Bob (Jul 6, 2007)

Hi Marc,



> Just an idea, wouldn't it be better to use flags instead of a script ID ?
> 
> A specific flag(s) could mean that EP0 contains tuning info, which makes this info available to all slots.



I just emailed you a copy of the source for the ISCS and after you have a chance to look it over you might see why I suggested what I did. How a script reacts to 'tagged' notes may depend on more things than certain characteristics of the note itself. By tagging notes with the SID, the receiving script can be designed to process such notes differently for each 'sender' script (if need be). The ISCS scheme provides a very generalized message passing system. 



> Btw, in my case I need 11 bits. 7 for note_off velocity (0-127) which is generated just before calling note_off(ev_id) and 4 bits for the channel info (0-15).
> But then it could be nice to have 2 extra ones to differentiate from value = 0 or value is not set.



Sounds like you can easily get by with 21 bits. What I would suggest then would be that we assign a unique, 11-bit SID to your script that no one else can use. Then all notes that you create should have EP3 'tagged' with your SID in the least 11 bits and you can then format the remaining 21 bits whatever way you please. Of course you will have to publish the field layout so that other scripters will know how to process data that you send.



> Currently, in auto mode, using only 4 ports, I need 11 keys (key 0 to key 11, or C-2 to B-2) to pass the encoded events, so when I detect these events I try to decode them, if a higher pitch is received, I exit the callback.



Here I suggest that you shift this sub-sonic range up by at least one note to *avoid using MIDI note 0*. Not only is the ISCS using note 0 as its 'messenger note' but many scripts have already been written to use MIDI note 0 for 'pseudo-calling' subroutines. 



> When the vst plug is enabled (a port is selected) it sends only note on events in that specific range. I could also implement a watch dog, the plug sending some CC every 5 seconds or so, but this could make things a bit complicated.
> If a user really needs C-2 to B-2, it's always possible to set the script to manual mode (on or off).



With the possible exception of some drum-kit-like instruments, I think few instruments are likely to need this sub-sonic range. If I understand you correctly you are saying when the plugin is present and active, only these subsonic note events will get through? If so, my reason for the slot 1 script to be able to 'auto-detect' the presence of the plug can easily be arranged. When your script gets a subsonic note it does its mapping thing and replaces the subsonics with a series of 'tagged' events (containing your SID). When a non-subsonic note is received by your script, just pass it through without any tagging added. I think this will provide the means needed for other scripts to know what to do with the notes they receive.



> The main problem is that I really have to turn off these events (note_on generated by the plug) or the voice buffer will grow to eventually reach the 8192 events limit, which is a bit annoying



I guess I don't really understand this last statement :? . Under what conditions do you have to 'turn off these events'. Is this some 'pre-K2' limit imposed by the VST plugin interface specs or some K2 limit or what? I don't know beans about plugins and such, as you can no doubt tell :oops: . But then I always say, no one can know everything about everything :lol: . 

And, as long as I'm in these 'unchartered waters', let me ask a few dumb questions. If one wants to run K2 standalone (driving it either from just a keyboard or from a MIDI-connected sequencer), would one still be able to use your plugin + script by either running one's keyboard 'through' a sequencer (with your plug inserted), or, could one use some extremely simple VST hosting program solely for the purpose of running the plugin?

Have a great day Marc,

God Bless,

Bob


----------



## Thonex (Jul 6, 2007)

HI Marc,

This sounds very exciting!!!!

I'm guessing this would be of particular interest for those who are using K2 inside a host application where K2 (because of VST limitations) would only allow 16 midi channels.

Cheers Marc o-[][]-o 

This could be a huge deal.... especially for NI since you need K2 to run it 

Thanks again!!

@ Big Bob,

Nice to see you trying to form some sort of "standard" here in our little world. If I had anything constructive to add, I would... this is a little over my head... except the part about using note # 0, I agree that it is used too often in other scripts and therefore we should assign a different "subsonic" (as you put it) note for carrying info.

T


----------



## Thonex (Jul 6, 2007)

Big Bob @ Fri Jul 06 said:


> If one wants to run K2 standalone (driving it either from just a keyboard or from a MIDI-connected sequencer), would one still be able to use your plugin + script by either running one's keyboard 'through' a sequencer (with your plug inserted), or, could one use some extremely simple VST hosting program solely for the purpose of running the plugin?



I'll take a stab at this.

There are a few applications that are VST hosts that have no other function than to just be a "Host "shell for hosting VST plugs and assigning them to various ASIO ports.

VStack is one of them.... Bidule ( Bob you would love this software) is another written buy some very clever French programmers... who REALLY know their midi stuff. You can do amazing things with Bidule... like assign anything to anything. It's a 100% modular object oriented environment which gives it immense flexibly... but it can also be a little intimidating.

I think (hope) I answered your question.

Cheers,

T


----------



## Big Bob (Jul 6, 2007)

> There are a few applications that are VST hosts that have no other function than to just be a "Host "shell for hosting VST plugs and assigning them to various ASIO ports.



Thanks Andrew, that's kind of what I thought but wasn't sure :? . And yes, even though I don't know 'beans' about plugins and such, I thought that what Marc is planning to do could be a very useful 'front end' for other scripts. It will be interesting to see how this plays out.

God Bless,

Bob


----------



## mbncp (Jul 6, 2007)

> I just emailed you a copy of the source for the ISCS and after you have a chance to look it over you might see why I suggested what I did. How a script reacts to 'tagged' notes may depend on more things than certain characteristics of the note itself. By tagging notes with the SID, the receiving script can be designed to process such notes differently for each 'sender' script (if need be). The ISCS scheme provides a very generalized message passing system.


I see that you spent a little more time on the subject than I did. 



> Sounds like you can easily get by with 21 bits. What I would suggest then would be that we assign a unique, 11-bit SID to your script that no one else can use. Then all notes that you create should have EP3 'tagged' with your SID in the least 11 bits and you can then format the remaining 21 bits whatever way you please. Of course you will have to publish the field layout so that other scripters will know how to process data that you send.


No problem. I will also provide a few example scripts.



> Here I suggest that you shift this sub-sonic range up by at least one note to *avoid using MIDI note 0*. Not only is the ISCS using note 0 as its 'messenger note' but many scripts have already been written to use MIDI note 0 for 'pseudo-calling' subroutines.


Can the note0 come from outside of k2 ? In that case I will indeed start with note 1.
Otherwise, as the script has to be in slot 1 there shouldn’t be any problems.




> When your script gets a subsonic note it does its mapping thing and replaces the subsonics with a series of 'tagged' events (containing your SID). When a non-subsonic note is received by your script, just pass it through without any tagging added. I think this will provide the means needed for other scripts to know what to do with the notes they receive.


Yes, that's what I'm doing now and it works fine.



> > The main problem is that I really have to turn off these events (note_on generated by the plug) or the voice buffer will grow to eventually reach the 8192 events limit, which is a bit annoying
> 
> 
> I guess I don't really understand this last statement :? . Under what conditions do you have to 'turn off these events'.


You can try this: hold a few keys on a keyboard, then turn off your synth or unplug the midi cable and you will see on the Engine tab in K2 that Note Events used doesn't go back to 0.
My plug sends only note on events and never the corresponding note off.
So one of the first thing I do (after note checking) is to call :
note_off($EVENT_ID)
ignore_event($EVENT_ID)
which works fine, the following script never get these messages and the Note Event queue is cleaned from these events. But it's important that I do that otherwise that queue grows up to 8192 and then bingo, no more new notes can be played. 
This one cost me a few aspirins :lol: 




> And, as long as I'm in these 'unchartered waters', let me ask a few dumb questions. If one wants to run K2 standalone (driving it either from just a keyboard or from a MIDI-connected sequencer), would one still be able to use your plugin + script by either running one's keyboard 'through' a sequencer (with your plug inserted), or, could one use some extremely simple VST hosting program solely for the purpose of running the plugin?



Most host now supports these VST-MIDI plugs. Or as Thonex sais there are plenty of "small" host that can deal with them.
My favourite one is VstHost from Hermann (free/donation ware), he even supports sysex, something that most host don't.
There are also more and more of these VST-MIDI plugs that can be very useful as they can process events before they reach K2, interesting in some situations.
Also you can create some crazy routing, having plugs working in parallel or serial, great fun 

As an example in this situation, to be able to use 64 "channels" in k2, all 64 instrument will need the decoding script, but only 4 instances of the vst-midi plug will be necessary, one for each port (4*16).

Anyway, if you have questions about vst just ask. (here or private)
I build the vst using Microsoft Visual Studio C++ express edition (free), so you will be able to have fun with c/c++ or even use assembling :mrgreen: 

Cheers,
Marc


----------



## Big Bob (Jul 6, 2007)

Hi Marc,

Thanks for all the info. I might even have mostly understood it :o . And, I'll bet that 8192 thingy was a real Excedrin-type headache! :roll: 



> Can the note0 come from outside of k2 ? In that case I will indeed start with note 1.
> Otherwise, as the script has to be in slot 1 there shouldn’t be any problems.



While note zero isn't likely to come from 'outside', it is very possible that you might want to use it in slot 1 for other things. For example, if you add to the function of your slot 1 script, you may want to communicate back and forth with other scripts farther down the chain. If you use the ISCS for these message services, it uses note 0 as a carrier of bi-directional data. Also, if the slot 1 script gets large, the day may come when you want to use 'pseudo-calling' of large routines referenced more than once in the script.

Overall, I just think it would be less likely to generate some future conflict if you avoided note 0. Why can't you just slide them up one note?

God Bless,

Bob


----------



## mbncp (Jul 7, 2007)

Hi Bob,
Ok, I won't use note 0, I also changed my encoding to a less conservative way, I'm now using note1 to note10 (really wanted to stay within the first octave :wink: )

Also, there will be basically 2 versions of the script, one that forwards channel information and one that doesn't.

The reasons are quiet simple. I need 4 arrays of 512 elements to store the noteID when using 16 channels (= 16*128). If channel info is not needed a single 128 array will do. If we have 64 instruments that don't care about that "internal" channel info we are using 4 MB of RAM and some processing for nothing.

The second problem is with CC as I can't attach a parameter to a CC, only to notes.
So to preserve channel information I will need to convert them to some NRPN.

Also, I want to leave the interface as simple as possible for the end user:
The script is always in AUTO mode, every events except note1 to note10 are passed as is. The user can then use the bypass button to turn the script off.

One Knob for Port selection : 1-4
One knob for channel selection : any(no filtering) or 1-16
By using channel filtering, it is virtually possible to have 1024 instruments (4*16*16) in a single instance of K2, each receiving it's own events >8o 

I will now create a NRPN table for the new events (for your approbation), as I think it's better if we use always the same values.

Btw, I need 2 scriptID's :wink: 

Cheers,
Marc


----------



## Big Bob (Jul 7, 2007)

Hi Marc,



> Ok, I won't use note 0, I also changed my encoding to a less conservative way, I'm now using note1 to note10 (really wanted to stay within the first octave )



Wise decision, I'm sure you'll be glad you avoided note 0 8) . 



> Also, I want to leave the interface as simple as possible for the end user:
> The script is always in AUTO mode, every events except note1 to note10 are passed as is. The user can then use the bypass button to turn the script off.



I would suggest that you also add a functional Script Bypass that doesn't require the KSP Bypass button. The reason is that with your script in the pre-eminent slot #1, we may want to add other needed pre-processing functions to it. For example, if I were to use your script, I would want to add at least the 'starter code' for the ISCS. This is merely some set_controller calls in the ICB and in the 'on ui_update' callback. However, it won't function if the KSP bypass is activated. Another good reason to use script-code bypassing is that you can make it MIDI controllable. You might consider something like the MIDI-Controllable Mode-Selection menu used in the SIPS-Legato V1.51 script.




> Also, there will be basically 2 versions of the script, one that forwards channel information and one that doesn't.



I think that's a good idea for users who aren't especially in need of more channels but would like to benefit from Aftertouch mapping, etc. However, if you implement the MIDI-controllable mode menu idea, maybe these two script versions could be rolled into one?



> Btw, I need 2 scriptID's



Marc I'll assign you SIDs 101 and 102 and for now and, I'll keep a few more in reserve (up to 109) for your future use. Please let me know what you will be naming these scripts for my SID registration records. We're all looking forward to getting our hands on this when you get it done.

God Bless,

Bob


----------



## mbncp (Jul 8, 2007)

Just a few ideas ...

As we don't really have a real timer function in KSP, I think that it could be useful that the VST-MIDI plugs could also send a message at a given interval.

Also a VST plug can detect if the transport bar is changing state, so I could also send a message when the sequencer starts or stops.

From the VST SDK, some of the info that is available to a plug. Note that not all host make all the info available:

```
struct VstTimeInfo
{
//-------------------------------------------------------------------------------------------------------
	double samplePos;				///< current Position in audio samples (always valid)
	double sampleRate;				///< current Sample Rate in Herz (always valid)
	double nanoSeconds;				///< System Time in nanoseconds (10^-9 second)
	double ppqPos;					///< Musical Position, in Quarter Note (1.0 equals 1 Quarter Note)
	double tempo;					///< current Tempo in BPM (Beats Per Minute)
	double barStartPos;				///< last Bar Start Position, in Quarter Note
	double cycleStartPos;			///< Cycle Start (left locator), in Quarter Note
	double cycleEndPos;				///< Cycle End (right locator), in Quarter Note
	VstInt32 timeSigNumerator;		///< Time Signature Numerator (e.g. 3 for 3/4)
	VstInt32 timeSigDenominator;	///< Time Signature Denominator (e.g. 4 for 3/4)
	VstInt32 smpteOffset;			///< SMPTE offset (in SMPTE subframes (bits; 1/80 of a frame)). The current SMPTE position can be calculated using #samplePos, #sampleRate, and #smpteFrameRate.
	VstInt32 smpteFrameRate;		///< @see VstSmpteFrameRate
	VstInt32 samplesToNextClock;	///< MIDI Clock Resolution (24 Per Quarter Note), can be negative (nearest clock)
	VstInt32 flags;					///< @see VstTimeInfoFlags
//-------------------------------------------------------------------------------------------------------
};

//-------------------------------------------------------------------------------------------------------
/** Flags used in #VstTimeInfo. */
//-------------------------------------------------------------------------------------------------------
enum VstTimeInfoFlags
{
//-------------------------------------------------------------------------------------------------------
	kVstTransportChanged     = 1,		///< indicates that play, cycle or record state has changed
	kVstTransportPlaying     = 1 << 1,	///< set if Host sequencer is currently playing
	kVstTransportCycleActive = 1 << 2,	///< set if Host sequencer is in cycle mode
	kVstTransportRecording   = 1 << 3,	///< set if Host sequencer is in record mode
	kVstAutomationWriting    = 1 << 6,	///< set if automation write mode active (record parameter changes)
	kVstAutomationReading    = 1 << 7,	///< set if automation read mode active (play parameter changes)
	kVstNanosValid           = 1 << 8,	///< VstTimeInfo::nanoSeconds valid
	kVstPpqPosValid          = 1 << 9,	///< VstTimeInfo::ppqPos valid
	kVstTempoValid           = 1 << 10,	///< VstTimeInfo::tempo valid
	kVstBarsValid            = 1 << 11,	///< VstTimeInfo::barStartPos valid
	kVstCyclePosValid        = 1 << 12,	///< VstTimeInfo::cycleStartPos and VstTimeInfo::cycleEndPos valid
	kVstTimeSigValid         = 1 << 13,	///< VstTimeInfo::timeSigNumerator and VstTimeInfo::timeSigDenominator valid
	kVstSmpteValid           = 1 << 14,	///< VstTimeInfo::smpteOffset and VstTimeInfo::smpteFrameRate valid
	kVstClockValid           = 1 << 15	///< VstTimeInfo::samplesToNextClock valid
//-------------------------------------------------------------------------------------------------------
};
```

If you think that some of this info could be usefull for a script, let me know.

Cheers,
Marc


----------



## Big Bob (Jul 8, 2007)

Hi Marc,



> Both versions will receive port and channel info, but one will forward this info to the following slots while one won't. The scripts being able to receive this channel info will need to be specific. Both use the same code, but there will be a SET_CONDITION, so other scripts receive that info as well.
> As an example, on a single instrument, using a single k2 channel (not set to omni) a script could receive a CC7 from channel 1 to 16. This volume information could then be applied to different groups. A single instrument could then work like a MULTI.



I'm probably not understanding some of this because I still don't see why you need two separate scripts as opposed to two operating modes of one script. :? Also, when you say there will be a SET_CONDITION, I presume you mean there will only be one source script that you can compile either the MPMC or the MPSC from it depending on how you set your conditional compiler directives? Maybe all my fog will clear up once I look at your actual script (I hope you write a lot of good comments in your code):wink: .

******************************************************************



> As we don't really have a real timer function in KSP, I think that it could be useful that the VST-MIDI plugs could also send a message at a given interval.



Marc, that sounds like a really great idea :D . If there was a periodic 'interrupt' (in the form of say a note event) generated by the plug, it might be the basis of solving a number of problems with KSP deficiencies. For example, there is no way to produce a callback from the ICB and, within a single script, there is no way to trigger a callback (other than the RCB) from another callback.

The latest version of the ISCS allows nested subroutine calling but it requires that a polling Call-Loop be started and maintained in the CCB. There are two problems with this. One is gòÚ·   \BCÚ·   \BDÚ·   \BEÚ·   \BFÚ·   \BGÚ·   \BHÚ·   \BIÚ·   \BJÚ·   \BKÚ·   \BLÚ·   \BMÚ·   \BNÚ·   \BOÚ·   \BPÚ·   \BQÚ·   \BRÚ·   \BSÚ·   \BTÚ·   \BUÚ·   \BVÚ·   \BWÚ·   \BXÚ·   \BYÚ·   \BZÚ·   \B[Ú·   \B\Ú·   \B]Ú·   \B^Ú·   \B_Ú·   \B`Ú·   \BaÚ·   \BbÚ·   \BcÚ·   \BdÚ·   \BeÚ·   \BfÚ·   \BgÚ·   \BhÚ·   \BiÚ·   \BjÚ·   \BkÚ·   \BlÚ·   \BmÚ·   \BnÚ·   \BoÚ·   \BpÚ·   \BqÚ·   \BrÚ·   \BsÚ·   \BtÚ·   \BuÚ·   \BvÚ·   \BwÚ·   \BxÚ·   \ByÚ·   \BzÚ·   \B{Ú·   \B|Ú·   \B}Ú·   \B~Ú·   \BÚ·   \B€Ú·   \BÚ·   \B‚Ú·   \BƒÚ·   \B„Ú·   \B…Ú·   \B†Ú·   \B‡Ú·   \BˆÚ·   \B‰Ú·   \BŠÚ·   \B‹Ú·   \BŒÚ·   \BÚ·   \BŽÚ·   \BÚ·   \BÚ·   \B‘Ú·   \B’Ú·   \B“Ú·   \B”Ú·   \BïÚ·   \BðÚ·   \BñÚ·   \BòÚ·   \BóÚ·   \BôÚ·   \BõÚ·   \BöÚ¸   \B•Ú¸   \B–Ú¸   \B—Ú¸   \B˜Ú¸   \B™Ú¸   \BšÚ¸   \B›Ú¸   \BœÚ¸   \BÚ¸   \BžÚ¸   \BŸÚ¸   \B Ú¸   \B¡Ú¸   \B¢Ú¸   \B£Ú¸   \B¤Ú¸   \B¥Ú¸   \B¦Ú¸   \B§Ú¸   \B¨Ú¸   \B©Ú¸   \Bª              òÚ¸   \B¬Ú¸   \B­Ú¸   \B®Ú¸   \B¯Ú¸   \B°Ú¸   \B±Ú¸   \B²Ú¸   \B³Ú¸   \B´Ú¸   \BµÚ¸   \B¶Ú¸   \B·Ú¸   \B¸Ú¸   \B¹Ú¸   \BºÚ¸   \B»Ú¸   \B¼Ú¸   \B½Ú¸   \B¾Ú¸   \B¿Ú¸   \BÀÚ¸   \BÁÚ¸   \BÂÚ¸   \BÃÚ¸   \BÄÚ¸   \BÅÚ¸   \BÆÚ¸   \BÇÚ¸   \BÈÚ¸   \BÉÚ¸   \BÊÚ¸   \BËÚ¸   \BÌÚ¸   \BÍÚ¸   \BÎÚ¸   \BÏÚ¸   \BÐÚ¸   \BÑÚ¸   \BÒÚ¸   \BÓÚ¸   \BÔÚ¸   \BÕÚ¸   \BÖÚ¸   \B×Ú¸   \BØÚ¸   \BÙÚ¸   \BÚÚ¸   \BÛÚ¸   \BÜÚ¸   \BÝÚ¸   \BÞÚ¸   \BßÚ¸   \BàÚ¸   \BáÚ¸   \BâÚ¸   \BãÚ¸   \BäÚ¸   \BåÚ¸   \BæÚ¸   \BçÚ¸   \BèÚ¸   \BéÚ¸   \BêÚ¸   \BëÚ¸   \BìÚ¸   \BíÚ¸   \BîÚº   \B÷Úº   \BøÚº   \BùÚº   \BúÚº   \BûÚº   \BüÚº   \BýÚº   \BþÚº   \BÿÚº   \C Úº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \C	Úº   \C
Úº   \CÚº   \CÚº   \C Úº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \CÚº   \C


----------



## mbncp (Jul 8, 2007)

Hi Bob,



> I'm probably not understanding some of this because I still don't see why you need two separate scripts as opposed to two operating modes of one script. :?



MPMC, the "complex" script uses more RAM, sends controllers, pitch bends as NRPN to conserve channel info and won't be used by many people. My main usage will be for my MIDI guitar so I can control each string in a different way.
But for people who just need more virtual channels (up to 64 instruments) or just want to receive aftertouch, the simple script is good enough.
And as I cannot allocate the arrays dynamically it would be a little overkill to have both in the same script. I mainly use the set_condition for debugging, as it's easier to debug with a single script.

I didn't add much comments (so far) but you can have a look here:
The simple one: http://homepage.hispeed.ch/mbncp/KSP/tmp/MPSC.html
The one that sends channel info: http://homepage.hispeed.ch/mbncp/KSP/tmp/MPMC.html
Both, using Set_CONDITIONhttp://homepage.hispeed.ch/mbncp/KSP/tmp/MPMC_MPSC.html
******************************************************************




> One nice way to solve this problem would be to have your script/plug combo issue a periodic CC event. Thus, if the KSP arbitrarily decides to abort the call-loop, it would quickly be re-started (before subroutine calls pile up in the queue). This would also solve the starup problem quite nicely. So, I definitely vote for a periodic 'interrupt' message from the plugin.



I see that it could be useful. I would add a slider that let us choose the time interval or turn it off. Now what would be a good range ?
The shortest is 1 sample (22 microsecond @ 44100hz), but that would be too much CPU usage and it's not even sure we would get all of them.
Any idea ?
And what about the CC to use, should it be fixed ? or selectable by the user ?

Note that I can always implement new stuff later, but once I have about 40-50 instruments set, I don't feel like reloading a new script everyday 
I hope NI will make us a utility that can automatically update a given script to all instruments  


Now I still have the problem with multi-notes, receiving the same key without the corresponding note off. What I do now, is to turn off that note, then trigger it again.
The complex script can play up to 16 times the same note as long as it comes on a different channel.
Another option would be to ignore the newest one. Or to allow up to 3 or 4 identical notes and turn them all off at the first note off event or to turn off the oldest one.
Any idea ?

Cheers,
Marc


----------



## Big Bob (Jul 9, 2007)

Hi Marc,



> I see that it could be useful. I would add a slider that let us choose the time interval or turn it off. Now what would be a good range ?
> The shortest is 1 sample (22 microsecond @ 44100hz), but that would be too much CPU usage and it's not even sure we would get all of them.
> Any idea ?
> And what about the CC to use, should it be fixed ? or selectable by the user ?



For what I have in mind, a fairly slow rate will be sufficient, on the order of 10 ms to 100 ms should be adequate (even 100 ms to 1000 ms might be OK). It will somewhat depend on how much drain on the KSP your script would exact. Is the rate of the source for this timer input selectable in the plug? If only some high-speed rate is available as a fast barrage of sub-sonic notes and the slot 1 script has to divide it down, that would be very demanding on KSP resources. I'd like to see the KSP be able to 'loaf' as far as servicing this timer function is concerned. BTW I thought of another use for this timer 'interrupt'. There are lots of situations in which it would be nice for a script to be able to 'flash' òÛ   \VÕÛ   \VÖÛ   \V×Û   \VØÛ   \VÙÛ   \VÚÛ   \VÛÛ   \VÜÛ   \VÝÛ   \VÞÛ   \VßÛ   \VàÛ   \VáÛ   \VâÛ   \VãÛ   \VäÛ   \VåÛ   \VæÛ   \VçÛ   \VèÛ   \VéÛ   \VêÛ   \VëÛ   \VìÛ   \VíÛ   \VîÛ   \VïÛ   \VðÛ   \VñÛ   \VòÛ   \VóÛ   \VôÛ   \VõÛ   \VöÛ   \V÷Û   \VøÛ   \VùÛ   \VúÛ   \VûÛ   \VüÛ   \VýÛ   \VþÛ   \VÿÛ   \W Û   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \W	Û   \W
Û   \WÛ   \WÛ   \W Û   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \WÛ   \W Û   \W!Û   \W"Û   \W#Û   \W$Û   \W%Û   \W&Û   \W'Û   \W(Û   \W)Û   \W*Û   \W+Û   \W,Û   \W-Û   \W.Û   \W/Û   \W0Û   \W1Û   \W2Û   \W3Û   \W4Û   \W5Û   \W6Û   \W7Û   \W8Û   \W9Û   \W:Û   \W;Û   \W<Û   \W=Û   \W>Û   \W?Û   \[email protected]Û   \WAÛ   \WBÛ   \WCÛ   \WD              òÛ   \WFÛ   \WGÛ   \WHÛ   \WIÛ   \WJÛ   \WKÛ   \WLÛ   \WMÛ   \WNÛ   \WOÛ   \WPÛ   \WQÛ   \WRÛ   \WSÛ   \WTÛ   \WUÛ   \WVÛ   \WWÛ   \WXÛ   \WYÛ   \WZÛ   \W[Û   \W\Û   \W]Û   \W^Û   \W_Û   \W`Û   \WaÛ   \WbÛ   \WcÛ   \WdÛ   \WeÛ   \WfÛ   \WgÛ   \WhÛ   \WiÛ   \WjÛ   \WkÛ   \WlÛ   \WmÛ   \WnÛ   \WoÛ   \WpÛ   \WqÛ   \WrÛ   \WsÛ   \WtÛ   \WuÛ   \WvÛ   \WwÛ   \WxÛ   \WyÛ   \WzÛ   \W{Û   \W|Û   \W}Û   \W~Û   \WÛ   \W€Û   \WÛ   \W‚Û   \WƒÛ   \W„Û   \W…Û   \W†Û   \W‡


----------



## Big Bob (Jul 9, 2007)

Hey Andrew,

Thanks for chiming in, I was pretty sure you would be interested in having Marc supply tempo sync info but, I see you added a few more.



> As to others not chiming in... I think aside from the regular "scripters" this goes well over everyone's head.


Yes, I understand that a lot of you can't participate in the discussion of design details but I thought naming some of the previously discovered 'holes' in K2 (and what kind of things you have been wishing could be addressed via scripting) might be appropriate at this time. For example, I know that a lot of users keep wishing that we could write scripts that could respond to aftertouch. And, I knew that you and several others have voiced concerns about the lack of tempo sync capability in stand alone mode. I just thought that there might be a longer list of such things 'kicking around in our collective heads' and I didn't want to be the only one articulating them.

*********************************************************************
Hi Again Marc,

I made a printout of your 101 script and took it with me to the dentist's office. I spent a little while with it in the waiting room and between 'fingers in the mouth' and such. :roll: 

Could you please post the details of the 'encoding' format you are using for the sub-sonic notes so I don't have to 'reverse' the 'decoder' logic to deduce it? Does your sub-sonic note creation algorithm preclude an input MIDI stream that contains 2 or more note-ons for the same note before the corresponding note-offs? I need to study your script a little more (after you give me the encoded input format) but at first glance, it seems like you are only using a single 128-element array to hold the ids of the notes you are generating. If so, what happens when 2 or more note-ons occur for the same note (before the corresponding note offs)?

I can think of several other ways of doing this sort of thing but, I probably should hold such discussions until you describe your encoding scheme, so I don't jump to any conclusions.

God Bless,

Bob


----------



## Mr. Anxiety (Jul 9, 2007)

Andrew is right. There was so much data flying around between the 2 posters here, that I just tried to keep up, let alone reply.

Tempo sync in standalone mode would be HUGE!!!!!!!!!!!!!!!!!!!!!!!!!!

Aside from being able to route audio from the standalone to 3rd party plug-ins as aux sends, i.e. adding guitar rig to a guitar sample instrument in K2 (my first request), tempo sync would be next.

Well maybe third, second would be SIPS + Nil's crossfade script living in harmony!

Keep up the great work. I wish I could help with the code, but notes are hard enough for me already!

Mr. Anxiety


----------



## Big Bob (Jul 9, 2007)

> Andrew is right. There was so much data flying around between the 2 posters here, that I just tried to keep up, let alone reply.



Hey there Mr A, glad to hear from you. :D I realize that we have been kicking around some rather technical things (that a lot of you could care less about) but, sometimes you have to skip the techno-jargon and zero-in on the big picture. Especially when it could impact you favorably by inserting some input.

Basically Marc was saying (and I paraphrase): "Here's a list of some of the things I could send the KSP from this plugin, which of these things do *you guys *think might be useful?" Since I'm not too representative of the way most of you probably use K2, I didn't want to be the only one speaking for *you guys*. :wink: 



> Well maybe third, second would be SIPS + Nil's crossfade script living in harmony!



V1.51 of SIPS theoretically *will *play in harmony with the VXF when Nils releases the next update. So, I'm afraid that ball is in Nils' court 8) 
********************************************************************
And Marc,

It just now dawned on me that a few posts ago when you were talking about what kind of 'interrupt' rate to use and whether you should provide a 'slider', etc. I was thinking about something you were going to put in your slot-1 script but I'll bet you were thinking about providing a slider or two in the plugin itself no? :oops: 

Are you thinking of providing the timer function by sending a periodic CC message directly from the plug itself? If so, I think a clock rate of 10 pps (100 ms period) would be excellent. This is slow enough that it shouldn't sap a lot of the KSP's horsepower when dividing it down. A faster clock might be more flexible for future demands but it would come at the expense of taxing the KSP which I'd rather not do *unless someone knows of a specific situation for which we must have finer resolution*. For simple watchdog and blinking applications 100ms should be fast enough. By dividing it down in the script by 3 or 4 we can easily derive a nice half-period for blinking, etc. For 'kick-starting' stalled loops, 100ms should be a quick enough recovery time. I don't think we should try to use this clock to control any realtime performance issues so let's leave the horsepower for the KSP to handle those things in the usual way. For auxiliary timing functions mostly related to the UI, 10ms to 100ms ought to do the job and I think I would favor 100ms.

God Bless,

Bob


----------



## Mr. Anxiety (Jul 9, 2007)

Marc, Big Bob,

Although I use your scripts mainly for playing orchestral samples in [email protected], which does not really require any midi clocking from the host, if you were to try and enable midi clock receive from a host, in standalone K2 mode, it has to work really well, or it doesn't help.

So if your last exchange about clock speeds to KSP affect the plug in's ability to stay clocked to a host sequencer, you need to make sure it does it really well.

As of now, no VST host does this well enough to be really happy. Forte being the closest. And of course, VStack does not do it.

My 2 cents.

Mr. A.


----------



## mbncp (Jul 10, 2007)

Thonex, Mr. A,
I'm not sure exactly what you want the tempo stuff for, but just be aware that it is not possible to set K2 tempo from within a script. So any function within K2 which uses the tempo would not be in sync, example a delay synced to 1/8 or whatever.
Also the tempo value that a plug receives is only valid for the start of the current audio buffer. With a large buffer, there could be some errors. 
Off course, I could send some events every n samples related to the current tempo, but be aware that this event has to be sent to every instrument which would probably overload your CPU at some point.
Tempo sync is really something that should be handled between hosts.

************************************************
Hi Bob,
For the encoding here's an example.

Let's say I receive a CC105 on channel 4 with a value of 64, and I need to send it to port 2.
The incoming (received by the vst plug) MIDI message would be:
0xB3 105 64 (I use the 0x notation for hexadecimal display)
So I send 3 note on messages:
0x93 2 0x33 (note on channel 3, note = 2 means Port2, 0x33 is 0xB3 - 0x80)
0x93 5 105 ( I use note 5 for sending the remaining data bytes)
0x93 5 64 ( second data byte)

NOTE: I never send the corresponding note off event from the vst plug, that's why it is important that the script calls :
note_off($EVENT_ID)
ignore_event($EVENT_ID)
whenever it receives an encoded message. (my 8192 events issue)

The first events gives me the Port, event type and event channel, while the two next one carry the 2 data bytes.

For the "subsonic" notes
note 1 = port 1
note 2 = port 2
note 3 = port 3
note 4 = port 4
note 5 = data byte 1 or 2
Then I have a problem, if the last value is 0, this would mean it's a note off event (note on with velocity = 0 means note off), so I would never receive this note, at least not the way I want it, in case I just increment the note by 5:
note 6 = port 1 (velo = 0)
note 7 = port 2 (velo = 0)
note 8 = port 3 (velo = 0)
note 9 = port 4 (velo = 0)
note 10 = data byte 1 or 2 (velo = 0)

That's why, in the script, when decoding I have this:
if($EVENT_NOTE > 5)
$v1 := $EVENT_NOTE-5
$v2 := 0
else
$v1 := $EVENT_NOTE
$v2 := $EVENT_VELOCITY
end if



> it seems like you are only using a single 128-element array to hold the ids of the notes you are generating. If so, what happens when 2 or more note-ons occur for the same note (before the corresponding note offs)?


Here we are not speaking about the encoded events, right ?
In a perfect world we should never receive the same note event without receiving first the corresponding not off event.
In case of the Multi Channel script, I can handle up to 16 times the same note as long as there are all on a different channel.

But different options could be possible:

1) Turn off the previous note and trigger a new one (what I do now) 
2) Ignore the new note
3) Ignore the new note but increase the volume of the previous one
4) Allow a given number of identical notes (3,4 .. ?) , then on note off:
a) Turn them all off (K2 standard behaviour)
b) Turn off the oldest one after each note off event
5) Trigger a trumpet sample o=< 

Anyway, the vst plug is ready to make some test (still missing a few options), working on the doc right now.

Cheers,
Marc


----------



## Big Bob (Jul 10, 2007)

Hi Marc,

Thanks for the encoding info, it made it a lot easier to follow the logic of your script. Looks like you thought it all out pretty well so I'll just comment on a few minor issues and respond to one of your earlier posts.



> Now I still have the problem with multi-notes, receiving the same key without the corresponding note off. What I do now, is to turn off that note, then trigger it again.
> The complex script can play up to 16 times the same note as long as it comes on a different channel.
> Another option would be to ignore the newest one. Or to allow up to 3 or 4 identical notes and turn them all off at the first note off event or to turn off the oldest one.
> Any idea ?



Now that I've read your encoding discussion and 'walked thru' your script, I think I finally understand what you were saying in the above quote (that you posted a while back). Of course multiple 'overlapping notes' of the same pitch can originate from a sequencer (usually when the musician is trying to achieve some kind of legato effect). I does seem that K2 simply stacks up such notes (polyphonically) until the first note-off at which time it ends all of them. I suppose you could try to mimic that behavior (to some max depth) but the additional arrays and/or the extra code devoted to this sort of thing might be somewhat like using a bulldozer to knock over a feather.

One way to reduce the number of arrays that would be needed would be to use event marks. Whenever a specific note-on occured more than once (before the note off) you could 'tag' each member of that set with the 'next available' MARK[n]. Then, when the note-off for the set occured, all the notes in the set could be turned off with one command (using the negative id for its assigned mark). The problem with this is that there are only 28 marks available to be spread over the entire 128 MIDI notes. So once the number of duplicated notes (across the entire 128 MIDI note range) exceeded 28, you would have to retire the oldest set. Sounds kind of messy and besides, event marks are used by other scripts and conflicts would abound. If the KSP provided some way to access polyvars 'out of context' one might also be able to cook up something similar to the event mark idea but not so constrained.

I might add that if one is overlapping notes to achieve a legato effect, the effect can be had using the SIPS-Legato script and the sustain pedal (without the need to actually overlap notes of the same pitch). So, overall, I think the value of 'properly' handling overlapping notes (of the same pitch) probably isn't worth the effort and, the way you have it now is probably as good as any way to handle it with a minimum of fuss.

On another related topic, if you would like to avoid 'ignoring' and regenerating note-ons, you might consider using the change_note function. To illustrate what I'm suggesting I changed a few lines of your 101 script and flagged the regions with the alternate comment delimiters (**). Here's the section with the edits.
*on note*
``*if*(iport = -1* or *EVENT_NOTE = 0* or *EVENT_NOTE > 10)
````*step* := 0
````exit _{script is off, or not from K2 Port VST plug}_
``*end if*
``_(* *)_
``*if*(ui_changed > 0* and **step* = 0)
````iport := *Port*
````dec(ui_changed)
``*end if*
``*if*(EVENT_NOTE > 5)
````v1 := EVENT_NOTE-5
````v2 := 0
``*else*
````v1 := EVENT_NOTE
````v2 := EVENT_VELOCITY
``*end if*
``*if*((v1 < 5* and *iport = 0) *or* iport = v1)
_(**)_``note_off(EVENT_ID)
``````ignore_event(EVENT_ID)
````*step* := 0
````chn := v2 .*and*. 15
````*if*(inchn = 0* or *chn = (inchn-1))
``````*step* := 1
``````type := sh_right(v2, 4)
``````exit
````*end if*
``*end if*
``*if*(*step* = 0)
````exit
``*end if* 
``*if*(v1 = 5)
````*if*(*step* = 1)
_(**)_````note_off(EVENT_ID)
````````ignore_event(EVENT_ID)
``````*step* := 2
``````dt1 := v2
``````exit
````*end if*
````*if*(*step* = 2)
``````dt2 := v2
``````*if*(type = 1* and *dt2 = 0)
````````type := 0 _{note off}_
``````*end if*
``````*select*(type)
````````*case* 0 _{note off}_
``````````*if*(%keys[dt1] > 0)
````````````set_event_par(%keys[dt1], 3, sh_left(dt2, 12) .*or*. scripid)
````````````note_off(%keys[dt1])
````````````%keys[dt1] := 0
``````````*end if*``
````````*case* 1 _{note on}_
``````````*if*(%keys[dt1] > 0)
````````````note_off(%keys[dt1])
``````````*end if*
_(**)_````````%keys[dt1] := EVENT_ID
````````````change_note(EVENT_Id,dt1)
``````````set_event_par(%keys[dt1], 3, scripid)
I think the above will work although it would only allow you to 'hang onto' few of the 'carrier' notes so there isn't much gain (and it would add a couple of code lines). 
Mostly this is just food for thought. 

EDIT*** Whoops! I just noticed that I forgot the *change_vel(EVENT_ID,dt2) *line

Regarding the CC to use for the timer 'interrupt', I spent a little time pondering this. K2 doesn't utilize any of the channel-mode messages (120..127) except for 120 and 123 (All Sound and All Notes Off). Unlike some synths, K2 doesn't seem to treat the other channel messages as though they were all-notes-off, at least not K2.2.1. So, we might be able to get away with using CC = 127 for the timer but it might be somewhat risky. NI might just decide to respond to some of these codes in future releases. Another potential problem might be if someone is using K2's MIDI out option and driving a synth that does respond to the channel-mode messges.

So, probably the safest thing to do would be to use CC = 119 and then just tell users not to assign that CC for other purposes. So, if you decide that you would like to use a fixed CC# for the timer, please use 119. If you do, I'll remove it from the CC assignment menus for future releases of SIPS so that at least users of SIPS will not be able to accidentally assign CC = 119 to any SIPS parameter. You can let me know on this one when you decide.

God Bless,

Bob


----------



## Big Bob (Jul 10, 2007)

HI Marc,



> Well, I could just extend the array to 2x128, or even easier, send the note on event before the note off.



I understood extending the array but I think the 'note-on before the note-off' idea must have sailed over my head :? .



> If someone wants to give it a try, the vst plug is the MIDIIO_KSP.dll:


Whoopy! o=< I'll download it now but then I guess I will have to assess my host sequencer (Power Tracks). I don't think my installed version supports VST (but the last update, which I haven't installed yet, may). Alternatively, or in addition to, I might download one of your suggested free standalone VST Hosts.

Now all I've got to do is figure out how to use all this stuff that I have been avoiding :lol: . I guess I've got my work cut out for me huh?



> Only the "simple" script is included: MPSC.



Great, I'm a simple kind of guy :wink: 

God Bless,

Bob


----------



## mbncp (Jul 11, 2007)

Hi Bob,



> I understood extending the array but I think the 'note-on before the note-off' idea must have sailed over my head :? .


Well if the idea is to have an overlapped (legato note) it's not the case now when receiving a second time the same note, as I first turn off the note then I trigger it again.
The idea is to first trigger that note again, and on the next line turn off the previous one, this way the following script would see it as an overlap and not as 2 successive notes. Anyway, I think I will take the double or triple array road.



> Now all I've got to do is figure out how to use all this stuff that I have been avoiding :lol: . I guess I've got my work cut out for me huh?


I'm not sure Power Tracks can handle VST plugs that send MIDI to another VST(i).
I suggest that you try VSTHost from Hermann, make sure to get the latest version: http://www.hermannseib.com/programs/vsthostbeta.zip
I will now write a little doc to get you started quickly, should be ready in a few hours.



> Great, I'm a simple kind of guy :wink:


That's what first comes to mind when looking at the code in SIPS :lol: 

I'll finish the other scripts later, as it's a bit a pain to work on 3 at the same time.

Cheers,
Marc


----------



## Big Bob (Jul 11, 2007)

Hi Marc,



> Well if the idea is to have an overlapped (legato note) it's not the case now when receiving a second time the same note, as I first turn off the note then I trigger it again.
> The idea is to first trigger that note again, and on the next line turn off the previous one, this way the following script would see it as an overlap and not as 2 successive notes.



If by 'on the next line' you are simply refering to the order of the 'calls' in the NCB: ie play_note() followed by note_off(), I don't think that will work (unless maybe you put a short wait() call in between). K2 doesn't act on any of these calls until the callback exits and then K2 likes to queue them in its favorite priority order. :roll: 



> I'm not sure Power Tracks can handle VST plugs that send MIDI to another VST(i).
> I suggest that you try VSTHost from Hermann, make sure to get the latest version: http://www.hermannseib.com/programs/vsthostbeta.zip



According to the User's Guide that came with the latest version 11 of PT, they are claiming full VST support now but I'm still running V10 so I won't know for sure until I get around to updating. In the meantime I downloaded VSTHost and the .pdf User's Guide last night. Now, all I have to do is find an uninterrupted block of time to crawl in a corner somewhere and start reading to get up to speed. If not before, I'll have a big block of time this weekend because I have to take my wife 'down the hill' for some medical tests.



> I will now write a little doc to get you started quickly, should be ready in a few hours.



That's great, I need all the help I can get when it comes to this stuff :? 

Something popped into my head this morning when I woke up, regarding your script. If we want to keep your sub-sonic 'carrier' notes completely out of all the following scripts in slots 2..5 (which I think we should do) , I'm pretty sure you will need to add a RCB to your script. Perhaps something like this:

*on release*
``*if* in_range(EVENT_NOTE,1 10)
````ignore_event(EVENT_ID)
``*end if*
*end on*

The reason I think you need this is because the KSP first propagates the note-on (via NCB triggers) thru the script chain from slot 1 to slot 5 and thence to the K2 synth engine. Similarly, when a note-off occurs, the RCBs are triggered sequentially from the script originating the note thru the chain and thence to the synth. If you 'break' the NCB chain with an 'ignore()' call, the note-on is stopped in its tracks at the script slot issuing the ignore() but this has no effect on the subsequent note-off action. In fact this situation creates what I termed an 'Orphan Event' on page 8 of my 'Note/Release Callbacks, Study and Report'. Therefore, I think your note_off call will create a series of RCB triggers that will ripple through the script chain until it encounters a script with an 'ignore()' call in its RCB. I haven't actually tested this with your script but if my memory serves me correctly (which it often doesn't), I'll bet that if you put a script in a higher slot you will find the KSP triggering all the release callbacks. If my theorizing is right, putting the above code in your RCB should contain the subsonic notes from 'leaking' out :D .

The only thing that may be wrong with the above is I'm not sure about the 8192 event queue thing. I am assuming that the note_off() call will do the trick for that regardless of whether or not it is subsequently 'ignored' in the RCB but you'll have to check this out with your test setup.


> Anyway, I think I will take the double or triple array road.



That of course will work but, it will certainly add more execution-time overhead to note processing and I'm not sure the benefit justifies it. Maybe you could make it an option so those users who don't overlap notes of the same pitch won't have to incur a performance penalty.

BTW I have a preliminary question. After quickly skimming your documentation it's not clear whether the KSP Timer produces CC messages directly or in encoded format?

I'm kind of looking forward to 'getting into' all this stuff but, I just hope my old brain can retain enough of it to use it later. That seems to be my biggest problem these days :( but, I guess it could be worse :lol: 

God Bless,

Bob


----------



## mbncp (Jul 11, 2007)

Hi Bob,


> If by 'on the next line' you are simply refering to the order of the 'calls' in the NCB: ie play_note() followed by note_off(), I don't think that will work (unless maybe you put a short wait() call in between). K2 doesn't act on any of these calls until the callback exits and then K2 likes to queue them in its favorite priority order. :roll:


Yes that's what I mean about the next line. Will need to make a few test.



> According to the User's Guide that came with the latest version 11 of PT, they are claiming full VST support now but I'm still running V10 so I won't know for sure until I get around to updating. In the meantime I downloaded VSTHost and the .pdf User's Guide last night. Now, all I have to do is find an uninterrupted block of time to crawl in a corner somewhere and start reading to get up to speed. If not before, I'll have a big block of time this weekend because I have to take my wife 'down the hill' for some medical tests.


I just downloaded PT demo (v11) and I will give it a try. Let you know



> Something popped into my head this morning when I woke up, regarding your script. If we want to keep your sub-sonic 'carrier' notes completely out of all the following scripts in slots 2..5 (which I think we should do) , I'm pretty sure you will need to add a RCB to your script. Perhaps something like this:
> *on release*
> ``*if* in_range(EVENT_NOTE,1 10)
> ````ignore_event(EVENT_ID)
> ...


If in slot 1 I have a script that does just this:
---------------------
on note
note_off($EVENT_ID)
ignore_event($EVENT_ID)
end on
-------------------------
The following slots never get a single note on or release callback. Only slot1 receives the RCB. So adding an RCB will force an RCB in slot1, which is not necessary.
And the event queue doesn't grow either (8192 limit)
So on this side, I think it's fine, at least until next K2 version :wink: 
Now, I'm sure some other problems will show up sooner or later, as I havn't try every situation. But I may also wait for next K2 update to fix specific issues, as a few things may change by then.
One thing is sure, it's not tomorrow that we will have multi-ports in vst, maybe vst3, but then both the host and the plugs will need an update. And for myself, I would really like a single instance of k2 pre-loaded with about 40-50 instruments, so when I play music I just play music, not starting thingink, looking around for my patches and so on. Cubase has a nice little notepad for each track where I write down the CC I use for the current track/instrument, makes it really easy for my old brain 



> That of course will work but, it will certainly add more execution-time overhead to note processing and I'm not sure the benefit justifies it. Maybe you could make it an option so those users who don't overlap notes of the same pitch won't have to incur a performance penalty.


Fine, I'll leave it as is for now.


> BTW I have a preliminary question. After quickly skimming your documentation it's not clear whether the KSP Timer produces CC messages directly or in encoded format?


I send a CC (never encoded). Both are separated, endoding is done if KSP_Port is set to 1-4, when set to off, events are sent as is, and the timer will run when the KSP_Timer is set to ON. For the timer, you don't even need a script, just make sure KSP_Port is set to off.



> I'm kind of looking forward to 'getting into' all this stuff but, I just hope my old brain can retain enough of it to use it later. That seems to be my biggest problem these days :( but, I guess it could be worse :lol:


This vst stuff is indeed a bit tricky as a plug can receive audio and/or midi and send out audio and/or midi. Then each host has a different way to handle this.
So the problem is more on how to setup things on a given host, after it's easy.

Cheers,
Marc


----------



## mbncp (Jul 11, 2007)

Hi again Bob,
No luck with power-tracks and MIDI plugs. :( 
Best would be to send your MIDI using a virtual-midi cable (midiyoke, maple, ..) and use vsthost to host the plug and k2. Ever used a virtual midi cable ?
Cheers,
Marc


----------



## Big Bob (Jul 11, 2007)

Hi Marc,



> If in slot 1 I have a script that does just this:
> ---------------------
> on note
> note_off($EVENT_ID)
> ...



Yes, I know, *and that is precisely what I am worried about *:roll: . When I tested for this sort of thing before, I'm almost positive that a note_off(), *from any script*, triggers an RCB starting from the origin script and rippling forward all the way to the synth engine (unless stopped by an 'ignore' call in one of the RCBs). I don't think that the fact that you have no RCB in slot 1 will keep other slots from having their RCBs triggered (if they have them). Have you actually tried putting another script in a higher slot that has an RCB that can 'catch' any sub-sonic note events and announce them? Of course if you have and the RCB is never triggered (by notes 1..10), then I guess I must be wrong in my remembrance.

The other thing that might come into play here is that the KSP may behave differently for Orphan notes that are *not in 'active' zones*. Since none of an instrument's groups are likely to have notes 1..10 actually mapped to any playable zones, this may make a difference. The rules of RCB triggering are indeed arcane and often illogical so nothing in this area surprises me too much. However, I think I will try to revisit my test scripts and conduct a little experiment to see if I can confirm what you are saying (and see why it differs from what I remember :oops: ).



> I send a CC (never encoded). Both are separated, endoding is done if KSP_Port is set to 1-4, when set to off, events are sent as is, and the timer will run when the KSP_Timer is set to ON. For the timer, you don't even need a script, just make sure KSP_Port is set to off.


I'm not quite sure I follow the part about turning off the KSP_Port. If the Timer CC is generated in non-encoded format (by the way on what MIDI channel), doesn't it just come out of the Host mixed in with the plugin's input MIDI stream (encoded of course)? I guess I'm still not too clear on all this 'port' jazz but are you saying that if I turn on the KSP_Port (whatever that means) that the Timer CC will cease to come out of the host? or, will then start coming out of the host in encoded form? or none of the above :? 



> No luck with power-tracks and MIDI plugs.



Hey Marc, thanks for taking the time to do that. You've probably saved me a big hassle. I was just assuming that this statement in the V11 manual, "PT 11 supports VST effect plug-ins as well as VSTi softsynths" had it covered. That shows you what I know. Are you saying that their statement doesn't cover what we are trying to do? If nothing else, maybe I'll come away from this knowing something about plugins :oops: 



> Best would be to send your MIDI using a virtual-midi cable (midiyoke, maple, ..) and use vsthost to host the plug and k2. Ever used a virtual midi cable ?



No I never used a virtual MIDI cable or anything like Rewire, etc. I've just been doing it in the most obvious way. I run both PT and K2 standalone. I send the output of PT to a physical MIDI-Out jack, connect that to a pysical MIDI-In jack and assign that input jack to K2. I think I vaguely remember looking into MIDI Yoke once upon a time but something about it's description turned me off (but again, with my memory who knows, I may just have imagined the whole thing :wink: ).

God Bless,

Bob


----------



## Big Bob (Jul 11, 2007)

Hi Marc,

For the construct:

note_off($EVENT_ID) 
ignore_event($EVENT_ID) 

Amazingly, it does make a difference which order these are written in :o . With them in the order you have them, no more NCB or RCB triggering occurs as you have stated. Whereas, if the ignore is done first, not only do the RCBs trigger but all the NCBs trigger as well! :shock: . It's as though the note_off cancels the 'ignore'.

In every situation like this that I have investigated before, the ordering of the calls (as long as a wait() call isn't made) has never seemed to matter. Obviously though I have not tried every situation but one would like to think that there is some uniformity of behaviour so we don't have to investigate all possible combinations of things :roll: . The KSP continues to defy being put into any kind of straight jacket of predictable behavior. I wonder what else awaits us in the next update :lol: .

Anyway, the bottom line is (at least for K2.2.1) that what you have does just what you want (and just what you said it did). So, please excuse the false alarm. Maybe I should 'retire to Sussex and keep bees' :wink: .

God Bless,

Bob


----------



## Thonex (Jul 11, 2007)

Big Bob @ Wed Jul 11 said:


> Hi Marc,
> 
> For the construct:
> 
> ...



This is very useful info. Killing RCBs this way is a great solution.

Cheers,

T


----------



## Big Bob (Jul 11, 2007)

Hi Marc,

After seeing the difference that changing the order of 'note_off' and 'ignore' had, I got to thinking about your idea of doing the note-on first. It also occured to me that for multiple note-ons (for the same pitch, K2 may do the work of grouping them for you!. I ran a quick test with 3 overlapping notes. The first note-on occurs and that note sustains for 24 bars. The 2nd note-on occurs a beat later (tnan the first note-on)and also sustains for 24 bars. The 3rd note-on occurs another beat later but only sustains for 1 bar. When the note-off for the 3rd note occurs, K2 nicely ends all 3 note events  .

This leaves me to believe that you could just drop the conditional note-off when the id array contains the id of a prior note of the same pitch. Merely overwrite the prior id with the new one each time another occurance of the same pitch comes along. When a note-off finally occurs at this pitch, just issue a note-off for the id of the last note received and I think K2 will end all prior notes of that pitch that are still sounding.

I tried some tests to verify that this works but I don't have a convenient means of generating your encoded note stream. So, why don't you try this with your test setup and see what happens. I'll attach my edited version of your 101 script (at least as much of it as the forum will take as BB Code). If this works, you won't need any more arrays nor any additional processing time. :D 

*on note*
``*if*(iport = -1* or *EVENT_NOTE = 0* or *EVENT_NOTE > 10)
````*step* := 0
````exit _{script is off, or not from K2 Port VST plug}_
``*end if*
``_(* *)_
``*if*(ui_changed > 0* and **step* = 0)
````iport := *Port*
````dec(ui_changed)
``*end if*
``*if*(EVENT_NOTE > 5)
````v1 := EVENT_NOTE-5
````v2 := 0
``*else*
````v1 := EVENT_NOTE
````v2 := EVENT_VELOCITY
``*end if*
``*if*((v1 < 5* and *iport = 0) *or* iport = v1)
_(**)_``note_off(EVENT_ID)
``````ignore_event(EVENT_ID)
````*step* := 0
````chn := v2 .*and*. 15
````*if*(inchn = 0* or *chn = (inchn-1))
``````*step* := 1
``````type := sh_right(v2, 4)
``````exit
````*end if*
``*end if*
``*if*(*step* = 0)
````exit
``*end if* 
``*if*(v1 = 5)
````*if*(*step* = 1)
_(**)_````note_off(EVENT_ID)
````````ignore_event(EVENT_ID)
``````*step* := 2
``````dt1 := v2
``````exit
````*end if*
````*if*(*step* = 2)
``````dt2 := v2
``````*if*(type = 1* and *dt2 = 0)
````````type := 0 _{note off}_
``````*end if*
``````*select*(type)
````````*case* 0 _{note off}_
``````````*if*(%keys[dt1] > 0)
````````````set_event_par(%keys[dt1], 3, sh_left(dt2, 12) .*or*. scripid)
````````````note_off(%keys[dt1])
````````````%keys[dt1] := 0
``````````*end if*``
````````*case* 1 _{note on}_
_(* if(%keys[dt1] > 0)
note_off(%keys[dt1])
end if *)_
_(**)_````````%keys[dt1] := EVENT_ID
````````````change_note(EVENT_Id,dt1)
````````````change_velo(EVENT_ID,dt2)
``````````set_event_par(%keys[dt1], 3, scripid)

God Bless,

Bob


----------



## mbncp (Jul 11, 2007)

> I'm not quite sure I follow the part about turning off the KSP_Port.


 :mrgreen: Sorry :oops: 
What I wanted to say is that the encoding and the timer are not related to each other.
The timer sends a "real" CC, it's never encoded.



> Are you saying that their statement doesn't cover what we are trying to do?


Correct. There are basically 2 kind of plugs, *VST* that process audio, and *VSTi*, the i being for instrument, "converting" midi to audio. Then you can have VST(i) plugs that deal only with midi, and, though more and more host support them, it's still not the case for all of them.



> No I never used a virtual MIDI cable or anything like Rewire, etc. I've just been doing it in the most obvious way. I run both PT and K2 standalone. I send the output of PT to a physical MIDI-Out jack, connect that to a physical MIDI-In jack and assign that input jack to K2. I think I vaguely remember looking into MIDI Yoke once upon a time but something about it's description turned me off (but again, with my memory who knows, I may just have imagined the whole thing :wink: ).


Ok, this can work, but it's not the best solution. Going thru your hardware midi interface is very slow compared to a software interface. 
I would recommend you to try the Maple driver http://www.hurchalla.com/Maple_driver.html as you can't enable the in and out port in the same application, to avoid loop backs.



> I tried some tests to verify that this works but I don't have a convenient means of generating your encoded note stream. So, why don't you try this with your test setup and see what happens. I'll attach my edited version of your 101 script (at least as much of it as the forum will take as BB Code). If this works, you won't need any more arrays nor any additional processing time.


 8) I give it a try

Cheers,
Marc


----------



## Big Bob (Jul 11, 2007)

Hi Marc,



> What I wanted to say is that the encoding and the timer are not related to each other.
> The timer sends a "real" CC, it's never encoded.



Thanks for clearing that up, I'm sure I will still have questions but I know a lot of this will clear up after I get a chance to study the VSTHost manual and then get to fire it up with your plugin.



> Correct. There are basically 2 kind of plugs, VST that process audio, and VSTi, the i being for instrument, "converting" midi to audio. Then you can have VST(i) plugs that deal only with midi, and, though more and more host support them, it's still not the case for all of them.



Ah so! In the light of that, I'm even more appreciative that you checked it out for me. I probaly would have thought I was just doing something wrong and all along it would have been a situation where you can't get there from here  . Thanks again for checking out PT11.



> Ok, this can work, but it's not the best solution. Going thru your hardware midi interface is very slow compared to a software interface.



Yes, I realize that it slows things down to MIDI-cable bandwidth but since I typically only do one instrument at a time (and usually solo-instruments, not 25-finger piano players :lol: ), I get by with it OK. When I was using Giga Studio it used to appear in the list of input ports that PT could drive but alas, Kontakt doesn't play that game.



> I would recommend you to try the Maple driver http://www.hurchalla.com/Maple_driver.html as you can't enable the in and out port in the same application, to avoid loop backs.



Thanks for the suggestion, I have been looking for something like this on and off for a while so I'll give it a try. I already downloaded it and as soon as I can, I'll fire it up. Right now I'm in the middle of a major SIPS revision that I kind of need to keep focused on for a little while (but I'm beginning to see some light at the end of the tunnel :wink: ).

Thanks for all your help (and your patience with me)

God Bless,

Bob


----------



## mbncp (Jul 11, 2007)

Hi Bob,

Sorry for distracting you from SIPS :oops: 

But before it's all mixed in my head again.
First, the note off trick doesn't work, it looks like notes generated in the script don't get the same treatment, I really have to turn them off myself. 
Which is finally a good thing, otherwise my pseudo 16 channels idea wouldn't work.

Now, using change_note isn't exactly the same than using note_off, ignore_event and trigger a new note.
If, in the script I call a note_off and then use change_note, the next script will receive the note_on event before the note off. (overlapped)
Now, if I delete the note on using the note_off, ignore_event trick, call the note_off of the previous note and then create a new note, the next script/slot will first receive a note off, followed by a note on (not overlapped), which isn't the same.
The reason is that, using a change_note won't move this event in the queue, so calling a note_off before or after change_note is the same thing.
But, when we totally destroy the event by using note_off,ignore_event, the engine removes that event from the queue, then it's first in, first out.

I don't know if it's clear what I writing here :oops: , but I think it's important, as the order of events in the queue may alter a script's behaviour.

Cheers,
Marc


----------



## Big Bob (Jul 11, 2007)

Hey Marc, already I'm in trouble :oops: 

I found a little time slot so I thought I would install the Maple Virtual MIDI Cable. While it seems to work OK (after only a very cursory check), I'm a little disconcerted by the lack of any way to uninstall it!

The install instructions say to Uninstall, just use the Windows Control Panel 'Add/Remove' applet. However, after I got done installing it, I don't find the program in the list of installed programs so it looks like they didn't include an uninstaller. Are you using this set of drivers and does yours have an uninstall method? Could it be that I unzipped the download file in a Data drive folder and executed it from there. Maybe I was supposed to first move it to the OS drive or put it in a folder or some such thing? While I'm waiting for your response, I think I'll restore the image I made prior to installing and then I'll try to repeat the process a little differently and see if that helps.

God Bless,

Bob


----------



## mbncp (Jul 11, 2007)

Hi Bob,

You need to go to:
Control Panel
Sytem
Hardware Tab
Device Manager button
Then look for Sound, Video and games controller
Right click on the device (I think it's called Maple ..) and click uninstall.
You may or may not have to reboot.

I'm not using the maple driver anymore, but loopbe30 (30 ports  ) but it's commercial, and not as safe as mapple.
Actually I was wrong about the maple driver it's even worse, you can't use a port more than once. 
So make sure that the sending app has only the out ports enabled and the receiving app only the inputs enabled.
It's hard to make it safer, but I find it a bit a pain as I love doing crazy routings 

Cheers,
Marc


----------



## Big Bob (Jul 11, 2007)

Hey Marc,

I'm really beginning to feel like a ninny :oops: I had already tried all the stuff you just suggested but it didn't appear in device manager either. But I found it now! After I restored my pre-installation image (which I always use Acronis to make before I install any new programs), and then carefully repeated the installation process, I finally found it in the Add/Remove programs applet, just where they said it would be :D .

And, guess what, I think it was there the last time too, *I just didn't see it *:oops: I was looking under Maple and Virtual and such and it ended up being under H (for *Hurchalla* Maple VMidi Cable). I dashed back to the VI Forum to delete my stupid post but you were faster :oops: . Sorry Marc, just another Big Bob false alarm. :wink: 

I hope my suggestion for handling multiple notes of the same pitch works out, I need something to go right to offset all my recent blunders  .

God Bless,

Bob


----------



## mbncp (Jul 12, 2007)

Hi Bob,
There is indeed some reasons to worry about MIDI drivers in winxp, as we are limited to 10 (not ports, drivers). I don't know if this has been fixed with later updates.
It is especially a problem with USB midi drivers, as each time you would plug your device in a different USB slot, XP would create a new entry, so it is( was) quiet easy to reach the limit.
You can always delete duplicate MIDI driver entries in the registry _HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32_, but you may delete the wrong one, and need to re-install the driver.

This tool from M-Audio, MIDI Fix, does it for you, cleaning the registry from unused MIDI drivers entries:
http://www.m-audio.com/index.php?do...=8&PID=99d9b0c3720fe6ac8291cecff1d84394&OS=15
Don't unplug any device (as stated in the readme), unless you want to re-install the drivers, just launch MIDIFIX.exe. It does a good job.



> I hope my suggestion for handling multiple notes of the same pitch works out


It looks like you missed my previous post :wink: 

Cheers,
Marc


----------



## Big Bob (Jul 12, 2007)

Hi Marc,



> It looks like you missed my previous post



I sure did old buddy, sorry :oops: (I'm really getting oversubscribed I guess :wink: ). I just printed out your post that I missed and as soon as I get my head clear, I'll try to digest it before I respond. But, I guess the bottom line is that my idea didn't work huh? K2 and the KSP always seem more adept at doing what we don't want rather than what we want them to do :lol: .

Unfortunately, I spent several hours last night trying to coax VSTHost to do something but was not succesful :cry: . I must be missing something very fundamental but no matter what I do I can't seem to get any MIDI output from VSTHost. I've tried it with and without your plugin installed, with and without bypassing things, with MIDI out assigned to various devices (including and excluding the new Maple ports), etc. VSTHost seems to 'hear' my keyboard because it's little keyboard keys go up and down when I hit mine. But no matter what I do, I can't seem to get my keyboard to 'come out of the other end' of VSTHost. I've also tried using MIDI Thru with various combinations. So far all I've been trying to do is drive K2 (standalone) from my keyboard, via VSTHost but K2 sees no MIDI input :( 

Now that I've had a good night's sleep, I'll try again but I don't know what I could be doing wrong. Any ideas?

God Bless,

Bob


----------



## Big Bob (Jul 12, 2007)

Hi Marc,

Well I just spent another couple of unfruitful hours trying to coax some MIDI data out of VSTHost. I thought I was going to enjoy fooling around with this plugin stuff but now I'm almost sorry I started into this:( .

Results today are pretty much as bad as last night but I did manage to make a new puzzling observation. If I use PT as the receiver of MIDI data, I can get some there from VSTHost if I use the little built-in sequencer and play a standard MIDI file. My PT keyboard then seems to indicate that it's getting MIDI data from VSTHost. However, I still can't just get my keyboard to go into and out of VSTHost and arrive anywhere that I can detect it.

Moreover, when I replace PT with K2 and play the MIDI sequence in VSTHost, all sorts of strange things happen; some of which seem to indicate that somekind of MIDI data is getting to K2 (enough to sometimes choke it and make it crash) although no sound is produced (but the K2 keyboard shows a flurry of activity). Thinking it might be a channelizing problem I set up just one instrument and set the MIDI channel to omni. Still no sound, just K2 keyboard activity???

All the tests this morning were done without loading your plugin. Last night I tried with and without your plugin loaded and with and without it bypassed.

Like I said, I'm almost sorry I got into this  , so I think I'll go study your post that I missed because I need to get away from VSTHost for a while (maybe a long while :lol 

God Bless,

Bob


----------



## Tod (Jul 12, 2007)

Hi Bob,

I'm not sure exactly what your looking for or what you need but if your looking for a host for VST plugins and VSTi instruments there's a program called "Reaper" you might want to check out or maybe you already have. It seems to have both a midi sequencer and audio capablilities. I've never personally used it but I've heard and read a lot of positive things about it. It's basically free although I think they want a small fee after you've had a chance to evaluate it.

If you haven't checked it out I think this is the link:

http://www.cockos.com/reaper/download.php

God bless you to my friend. :D 

Tod


----------



## mbncp (Jul 12, 2007)

Hi Bob,
Sorry to hear about your troubles :( 

I'll go thru a basic setup, just to use your keyboard in VstHost playing on K2 hosted in it:

Make sure that no other MIDI or Audio App is loaded now, icluding K2 standalone.
In VstHost, make sure you setup the audio and midi first:

It's all in the Devices menu:
MIDI:
In MIDI select the MIDI input you plan to use (Ctrl+click to select more than one).
I would leave MIDI out to none (nothing selected)
Leave MIDI thru and Remote Control untouvhed.
Then hit OK
WAVE:
Leave Input Port to No Wave
Select your ASIO driver in Output Port
Select a smple rate (probably 44100)
Select the Buffer size
ASIO Channel Selection
Input Channels -> No Channel Selection
Output Channels -> Select a channel pair that is available.

*Now, very important: Start the engine (Menu Engine Run).*

It looks like you managed to insert a plugin.
So add an instance of K2.
Now click on the little window where it says Kontakt2.dll with all the litle icons around.
Then from the PlugIn Menu:
Assign output channels Sub-Menu:
Make sure you have at least 1 stereo pair set to Engine Output 1 and Engine Output 2.
Midi Devices sub-menu:
Select your midi keyboard from the list 

Now, when playing on your keyboard, you should see some red dots on that little window (left side) showing MIDI activity.

Open the Kontakt window (little knob icon).
At this point you should also see MIDI reaching K2 

Select a patch in K2, you should hear what you play.

Let me know,
Marc


----------



## Big Bob (Jul 12, 2007)

Hi Marc,

Thanks for the detailed instructions, however, after skimming them quickly, it looks like you are suggesting installing K2 as a VSTi plugin. I presumed that would work but I never tried it because I want to run K2 standalone.

One of my very earliest questions was whether or not I could run K2 standalone and still use your plugin (sort of in series between my keyboard and K2 or between my sequencer and K2). I'm beginning to get the sinking feeling that my initial questions (posted near the beginning of this thread) were misunderstood and that maybe what I had wanted to do isn't doable? :( 

If it is possible to run your plugin in VSTHost such that the combination acts as a MIDI processor, essentially in series with the MIDI stream between keyboard and K2 (or PT and K2), could you please outline the setup to achieve that. If this sort of thing isn't possible and it is required to run K2 as a plugin, then, I've been 'barking up the wrong tree' as they say :oops: .

After posting this, I'll read your post more carefully to see what else I might have failed to do during my experiments but, I just wanted to quickly note the bummer about K2 as a VSTi versus standalone.

God Bless,

Bob


----------



## Big Bob (Jul 12, 2007)

Tod @ Thu Jul 12 said:


> Hi Bob,
> 
> I'm not sure exactly what your looking for or what you need but if your looking for a host for VST plugins and VSTi instruments there's a program called "Reaper" you might want to check out or maybe you already have. It seems to have both a midi sequencer and audio capablilities. I've never personally used it but I've heard and read a lot of positive things about it. It's basically free although I think they want a small fee after you've had a chance to evaluate it.
> 
> ...



Hey Tod. thanks for the input old buddy.

Actually my interest in plugins is more academic than born out of any need. If you skim this thread from the top you'll probably get the picture. When Marc announced that he was writing a plugin to add some capability to K2, certain aspects of that seemed like it might be very useful but, since I had practically zero knowledge of plugins and such, I posted a few dumb questions. One thing led to another and I soon found myself quite happily involved. Marc is a pretty sharp cookie so I've enjoyed our banter back and forth.

However, it now turns out that my ignorance of plugin technology has caught up with me. :lol: I guess it may now turn out that what I thought I could do and what can be done may be two different things :oops: .

But anyway, it's great to hear from you my friend.

God Bless,

Bob


----------



## mbncp (Jul 12, 2007)

> I presumed that would work but I never tried it because I want to run K2 standalone.



Hi Bob,

Ok, sorry about that, but it's possible too.

In VstHost:
Menu: Devices -> MIDI : (see MIDI routing below)
Set as input the MIDI port you are sending from PT. (Maple1)
Set as output the MIDI port you send to K2 standalone. (Maple2)

Menu: Devices -> Wave -> *Set both port to No Wave, and set the Buffer to 44*
Make sure the Engine is Running: Menu Engine->Run must be checked

Now drag drop my plug (MIDIIO_KSP) into VSTHost.
Leave all settings as is but: (to view the settings click on the little icon left to the Red X), then elarge the window.
Set KSP_Port to 1 if you want the encoded events (using the MPSC script), back to Off for regular MIDI. 
Set KSPTimer to ON, to start receiving the Timer in K2. 

About the MIDI routing.
In PT:
MidiIn - > External Keyboard 
MidiOut -> Maple1

In VstHost:
MidiIn -> Maple1
MidiOut -> Maple2

In K2 Standalone :
MidiIn -> Maple2
MidiOut-> None 

In K2 make sure you select the correct port.

let me know,
Marc


----------



## Big Bob (Jul 12, 2007)

Hi Marc,

Thanks for the latest recipe (BTW I'm glad to hear that what I wanted to do can be done) and I'll give it a try in a few minutes and let you know how I fare. But let me first catch up on the missed posting.



> But before it's all mixed in my head again.
> First, the note off trick doesn't work, it looks like notes generated in the script don't get the same treatment, I really have to turn them off myself.



Yes indeed, of course you are right and, I should have realized it wasn't going to work. Generated notes are always subject to a different system of behavior than MIDI-stream notes. Just another wonderful KSP anomaly. :roll: Too bad it didn't work out though because it would have been a neat solution to the multiple note problem. I guess the change_note thing not working isn't as much of a loss though :| .

Just for kicks I tried having the slot 1 script generate the notes and a later slot turn off the last generated note (by a complex process of having slot 1 send the last id via ISCS). The reason I thought of trying it is because it works for MIDI-stream (or slot-0) notes, when the note-off is in slot 1. Thus the reason could have been related to the note_off needing to be issued from a later slot. Unfortunately this doesn't work either but maybe it's just as well because I'm sure you would like your script to be containable in one slot :lol: . 

I'll get back to you on the VSTHost thing.

God Bless,

Bob


----------



## Big Bob (Jul 12, 2007)

Hi Marc,

Sorry it took so long. Your recipe worked just fine and, moreover, I was also able to replace PT with my keyboard feeding VSTHost directly and that also works fine. :D 

The reason for the delay in reporting is that I had to study your hookup versus what I had been doing to see what the difference was. :? Essentially your hookup appeared to be the same as what I have been doing :? 

Here's what I think might have happened. When I first installed VSTHost, I obediently followed their setup procedure which, among other things, asked me to point the Wave Devices dialog to my ASIO sound card. At the end of the setup process, I set the ASIO channel selection to NONE (since I wasn't planning on routing any audio data via the plugin).

In the flurry of experiments that followed (with trying to get MIDI out of VSTHost), I don't think I ever re-visited the Wave Device dialog. Thus, I think K2 (which I launched much later) couldn't 'get its hands on the sound card' and I'm not sure exactly how K2 misbehaves under such circumstances (but obviously among other things it can't make any sound in my speakers :lol: ).

I suppose (during my wild experimentation) that I made all sorts of mistakes but I think the 'key' problem was not specifying to VSTHost to use 'No Wave'. In any case things seem to be humming now so I'll now try to test the timer and such. Many thanks for the winning recipe :lol: .

God Bless,

Bob

BTW Have you noticed that this thread is getting so long that its getting hard to find the end of it :D


----------



## mbncp (Jul 12, 2007)

Hi Bob,

Using K2 in vsthost as a vst plug is actually easier, that would also allow you to use some audio plugs. Also within a single host, the timer is sample accurate, while the timestamps used by MIDI drivers are 1 msec at best.
But if you prefer K2 standalone it's your choice, I'm not a salesman  
Be aware, in this case, that going thru vsthost for the MIDI will add some latency, so it's important that you set the buffer low (like 44 samples = 1 msec) in VSTHost (Devices->Wave) to keep latency really short.

In VSThost, file menu, you may also want to check both Autosave Performance and Autosave Plugs bank. To create different setups, you can use Save Performance As.. , so you can have a setup to use directly with your keyboard, and one to be used from TP, it's a little quicker this way.

It looks that your sound card can't share it's driver, that's why you had no sound in K2. Forgot about this as with mine I can use a few apps using the same driver, but different output ports.



> Just for kicks I tried having the slot 1 script generate the notes and a later slot turn off the last generated note (by a complex process of having slot 1 send the last id via ISCS). The reason I thought of trying it is because it works for MIDI-stream (or slot-0) notes, when the note-off is in slot 1. Thus the reason could have been related to the note_off needing to be issued from a later slot. Unfortunately this doesn't work either but maybe it's just as well because I'm sure you would like your script to be containable in one slot


I don't know, having a special script in the last slot could be interesting. Early scripts could delegate some actions to the last slot, making it easier to deal with mutiple scrips ...

Cheers,
Marc


----------



## Big Bob (Jul 12, 2007)

Hi Marc,

Now that things are cooking, I decided to spend a few happy hours playing with this thing while everything was still fresh in my mind (nothing like a painful experience to help drive it home :wink: ).

I think this is going to be really spiffy 8) . I checked out the KSP Timer deal and that is going to be very useful. I also checked out your script and a lot of combinations of the various knobs and such (both on the plug and the script) to make sure that I finally understand what all this stuff does. In the process I came up with a few questions and I may have uncovered a bug :( (probably in your script as opposed to the plug).

First the questions: 

1. When moving the port sliders (both in and out) on the plugin, after the long list of names runs out, a series of numbers appear. What's the story on that?

2. I could use a clearer explanation of the function of the KSP_Chn. The illustration you give simply sets this slider to ANY so there aren't any clues as to what setting it to a specific channel does. The function of all the rest of the sliders was quite clear.

Now, as to the possible bug. Unfortunately it's one of these turkeys that only occurs during a flurry of activity when some specific sequence is used. The few times it happened, I tried various sequences to get it to repeat but as of yet I haven't been able to distill it to its essence. It's centered around changing the Port knob on both the script and the plugin. It first occured as I was experimenting with various combinations to make sure I understood what these controls do. At the time I was testing the only NRPN-translated MIDI event that I could conveniently produce with my little keyboard, namely patch change. I realize that I may be able to use some of the MIDI mapping options with VSTHost to generate some of the other things like aftertouch, etc, but I haven't gotten to that stuff yet.

When the problem occurs, it's usually after setting the script and plug port #s differently to prove that the program change message doesn't get translated. Then when you move the scripts knob to ALL and generate another program change, expecting it to come through OK, instead either nothing happens (ie no NRPN 192), or on at least two occasions, a subsonic note is generated. One time it was note 10 but I don't remember what it was the 2nd time it occured (it could have been note 10 also but I don't think so). Each time that the script put out a sub-sonic note, I had to hit the Apply button again to clear the problem. I'm sorry that I can't give you a precise procedure yet to reproduce this problem. If I ever catch it in the act again, I'll try to bottle it :wink: .



> Using K2 in vsthost as a vst plug is actually easier, that would also allow you to use some audio plugs. Also within a single host, the timer is sample accurate, while the timestamps used by MIDI drivers are 1 msec at best.



I tried using K2 as a DXi plugin when I first got it and it seemed much more crash prone than in standalone (and as we all know, K2 crashes enough as it is without giving it any further encouragement :roll: ). Maybe K2 is more stable as a VST plugin? I guess one of these days I'll have to try it.



> In VSThost, file menu, you may also want to check both Autosave Performance and Autosave Plugs bank. To create different setups, you can use Save Performance As.. , so you can have a setup to use directly with your keyboard, and one to be used from TP, it's a little quicker this way.



Yes, I noticed all this kind of stuff when skimming the manual. I plan to read it more carefully come Sunday and Monday while I sit through Rosie's Medical tests. Since I already devoted so much time to this project, I may as well spend a few more hours looking at the bells and whistles, huh? :lol: 



> It looks that your sound card can't share it's driver, that's why you had no sound in K2. Forgot about this as with mine I can use a few apps using the same driver, but different output ports.



I have AP2496 (M-Audio or Delta) which is sort of a minimal card. Besides, that's the best idea I can come up with that would explain why things were not working for me originally even though I was basically doing everything else right. :?: 



> I don't know, having a special script in the last slot could be interesting. Early scripts could delegate some actions to the last slot, making it easier to deal with mutiple scrips ...



That's an interesting thought! Well, if I ever come up with another idea for some elegant way to handle the multi-note problem (with or without an extra script slot), I'll let you know.

Meanwhile, I think I had better get back to my SIPS upgrade. Thanks for all your help Marc and your valuable suggestions.

God Bless,

Bob


----------



## Big Bob (Jul 13, 2007)

Hi Marc,

I'm working on the next SIPS update, it's a transitional version that will lead to the inclusion of a formant-corrected portamento mode for the SLS. I'd like to include some optional features that will require that your new plugin (plus script) be installed in order to function. For example, I'm thinking of including Channel Pressure (Mono AT) in the list of assignable CCs (and I'll probably drop CC119 from my lists so the timer can have it exclusively). I have a bunch of ideas on how to make our scripts 'play together' in the most harmonious way and at the same time make some headway toward solving the general problem of cascading with other scripts.

I'd like to know if you are interested in a joint cooperative effort to bring this about. If so, I'll prepare a list of ideas in the form of a proposal. We can then kick that back and forth a few times and hopefully arrive at a set of objectives. Then we each do our own thing until we are ready to merge and test. The idea is that with a little foresight and planning, the end result should dovetail much nicer and also make some strides toward the general goal of making scripts play together harmoniously.

Let me know what you think and if you are interested I'll take the next step.

God Bless,

Bob


----------



## Big Bob (Jul 13, 2007)

Hi Marc,



> ‘Sounds like the bees will have to wait



I must be working too hard, that one sailed over my head too :? 



> Btw, how difficult would it be to make SIPS polyphonic, I mean that all parameters would be identical for all voices, but as we can have channel info now (plug and script), only events from the same channel would be monophonic. I guess that this would require to convert some variables to arrays and some extra coding.
> Now, I'm not asking you to do it, just let me know if I should forget about it



This question has, of course, arisen before :wink: . For the general situation it turns out to be very tricky indeed and since I have almost no personal need for it, I decided I could use the time it would take more profitably elsewhere :lol: 

However, in concert with your plugin/script, the picture is somewhat different. One of the major difficulties for the general situation is the logic to decide which note in the prior chord should move to which note in the new chord, etc. If each note is channel stamped and each channel only has to play monophonically, it may not be too difficult to extend the SLS to handle it. This is something that I would really have to spend some time thinking about, so, I'll put it on the back burner and visit it every so often.

As soon as I get past a few bottlenecks I'm in right now, I'll start jotting down some ideas of the best way to proceed such that we can each work autonomously but yet have a reasonable expectation of a harmonious outcome o/~ o=< 

Meanwhile, I guess the Bees can wait (whatever that means) :D 

God Bless,

Bob


----------



## mbncp (Jul 13, 2007)

Big Bob @ Wed Jul 11 said:


> Maybe I should 'retire to Sussex and keep bees' :wink: .


It's probably because it's the first time I heard that expression, but it sounded really nice to me, I was ready to pack my suitcases :D 

There are different reason to have polyphony:
1) A guitar is like 6 instruments playing monophonic (sorry to come back with my guitar story :oops: )
2) If you have 10 violins in your orchestra (using the same patch) it's much easier to deal with a single instrument, each voice on it's own channel.
3) I agree that playing chords can be a little tricky and it shouldn't be part of SIPS.
But as you say, a script or plug upstream could deal with it and provide "channel" information.
I'm currently (well I was) working on a plug that changes scales depending of the chord being played on the left side. All I do is wait a given time and then I try to build a chord. For real-time, something like that could be done.
Another trick is to do that offline, the first time, the plug is just “recording” the events. Then the plug tries to make the best distribution of the different channels, with the help of a few settings.

But I understand that you don't have a real interest for it, so if you think it's not too complicated, I would give it a try after next SIPS release.

Cheers,
Marc


----------



## Big Bob (Jul 13, 2007)

> It's probably because it's the first time I heard that expression, but it sounded really nice to me, I was ready to pack my suitcases



Hey Marc, this is really embarassing :oops: You were just 'playing back' one of my own expressions and I didn't pick up on it, shame on me (I *must* be working too hard) :roll: 

The first quote is a classic 'Sherlock Holmes' quote, probably second only to 'Elementary My Dear Watson'. But, I don't know your age so maybe you never even heard of Sherlock Holmes :lol: In case you haven't, Sherlock Holmes was a classic fictional detective from around the turn of the century. And, being an old geezer myself, I tend to quote old Sherlock quite often, especially when I have a knotty problem to solve. :? 

As to a polyphonic SIPS, maybe after we get everything humming with your plugin and script and after I add portamento .....

BTW When you said you were adding more options to filter the type of MIDI event that gets encoded, are you talking about something you are adding to the script or something you are adding to the plug? The reason I ask is that this may impact some of the ideas I was kicking around.

Also, some of the questions I asked several posts back seem to have fallen thru the cracks :wink: I'll just copy them forward to here because by now they have probably gotten buried.



> 1. When moving the port sliders (both in and out) on the plugin, after the long list of names runs out, a series of numbers appear. What's the story on that?
> 
> 2. I could use a clearer explanation of the function of the KSP_Chn. The illustration you give simply sets this slider to ANY so there aren't any clues as to what setting it to a specific channel does. The function of all the rest of the sliders was quite clear.



God Bless,

Bob

BTW I presume you will stay with your current NRPN assignments such as 192 for program change, 208 for Channel Pressure (mono AT), etc


----------



## mbncp (Jul 13, 2007)

> The first quote is a classic 'Sherlock Holmes' quote


Amazing, I totally missed that one. Could be due to the translation, doesn't sound as "neat" in french. Oh, and I will be 47 this monday, and although I read a lot I don't recall having read a single book by Sir Doyle, but plenty of holmes stories on tv :oops: 



> As to a polyphonic SIPS, maybe after we get everything humming with your plugin and script and after I add portamento .....


No problem, nothing really urgent, I can wait for my birthday 



> BTW When you said you were adding more options to filter the type of MIDI event that gets encoded, are you talking about something you are adding to the script or something you are adding to the plug? The reason I ask is that this may impact some of the ideas I was kicking around.


Only from the plug. This is important for the special events (patch change, aftertouch) as we cannot trigger them from a script. But it's off course optional.




> Also, some of the questions I asked several posts back seem to have fallen thru the cracks :wink:


 I didn't forget them, I just hoped you would forget about them :wink: 



> 1. When moving the port sliders (both in and out) on the plugin, after the long list of names runs out, a series of numbers appear. What's the story on that?


That's VSthost doing some funny things when I return an empty string. In VST all parameters are in the range 0.0 to 1.0 (32 bit float).
I already changed that, it now shows N/A, as I had to allocate a fixed range of available MIDI ports (32). 
If the 2 first parameters are set to host, it's the MIDI of the host that are used. If they are set to ports, then it is these ports that get/send the MIDI.
I prefer to use the ports of the plug, as it's a bit easier to route my stuff. So use one or the other, not both, or you may get some duplicates.
Sometimes I use both on output, the host one to the next plug, and the port one being sent to MIDI-OX, helpful for debugging.



> 2. I could use a clearer explanation of the function of the KSP_Chn. The illustration you give simply sets this slider to ANY so there aren't any clues as to what setting it to a specific channel does. The function of all the rest of the sliders was quite clear.


Ok, this is the channel of the encoded events.
Example:
You send events on channel 5 to the plug.
Then on the plug you set the output channel to 12
And, still on the plug, set the KSP_Chn to 4

The encoded events will be sent to the instrument with channel 12 in K2, but the encoded events will show up with channel 4. Now, in the script, if you set the Channel Knob to 8, no events will make it thru, because only events with the encoded channel set to 8 would be accepted.
This allows to access up to 1024 different instruments in K2. (4 ports of 16 k2 channels of 16 encoded channels). Not really useful, the main reason is for debugging or sound testing, as this is a way to solo a specific encoded channel.

So a more useful example:
You are sending 16 channels to the plug.
The plug output is set to channel 1, so K2 will receive all 16 channels on Channel 1.
The KSP_Ch is set to any (all)
Now, inside the script, the encoded events still have there original channel value.
But, if you want to solo a channel, you can use the Channel Knob to filter out the others.

But most of the time both values, the KSP_Ch from the plug and the Channel Knob of the script should be set to Any (All).

I hope it's clear because I'm not going to try to read what I just wrote 



> BTW I presume you will stay with your current NRPN assignments such as 192 for program change, 208 for Channel Pressure (mono AT), etc


Yes, I use these values as they are the real MIDI values, makes it easier.
In the multi channel version, even CC, pitch wheel, .. get converted to NRPN, to keep channel info. 192 is patch change channel 1, 193 is channel 2,..
It's actually easier to see them in hex notation (C0, C1,... CF).

Btw, for those who are not used with this stuff, this site is pretty good: http://www.borg.com/~jglatt/tech/midispec.htm

Cheers,
Marc


----------



## Big Bob (Jul 14, 2007)

Hi Marc,



> If the 2 first parameters are set to host, it's the MIDI of the host that are used. If they are set to ports, then it is these ports that get/send the MIDI.



I understood that, very functional, kudos.



> I hope it's clear because I'm not going to try to read what I just wrote



Thanks for the elaboration, I think I may actually understand it now :wink: . Let me see if I can summarize and then you tell me what I still have wrong :oops: .

If we have a barrage of MIDI events on all 16 channels coming into the plugin, if the Input Channel is set to a specific channel, the other 15 channels are thrown out. If the Input Channel is set to Any, all 16 channels of events enter the plugin. Once in the plugin these events may or may not be altered. Whether or not they are altered, if the Output Channel is set to a specific channel, all the MIDI events are now channel-stamped with that channel and will arrive at K2 over that channel. However, if some of the events inside the plugin are encoded into a series of sub-sonic notes (which arrive at K2 over the Output Channel), when the events are 'decoded' in the K2 Script, they will 'tagged' with the KSP_Chn.

In any case, it's all very clever Marc and I think I'm almost beginning to understand it :roll: .




> Yes, I use these values as they are the real MIDI values, makes it easier.
> In the multi channel version, even CC, pitch wheel, .. get converted to NRPN, to keep channel info. 192 is patch change channel 1, 193 is channel 2,..
> It's actually easier to see them in hex notation (C0, C1,... CF).
> 
> Btw, for those who are not used with this stuff, this site is pretty good:



I understand. Even though it probably doesn't sound like it at times, I actually have a fairly good grasp of the MIDI spec (or at least I used to :lol: ). I agree that this stuff is easier to comprehend in hex notation and I've been meaning to ask you why you didn't write your code using hex in the appropriate places (like for bit masks or as case-statement indices, etc). Maybe you aren't aware that, at my request some time ago, Nils kindly added C-style hex number input to his KScript Editor?



> No problem, nothing really urgent, I can wait for my birthday



I don't think I can give you a polyphonic SIPS for your birthday but, since I'm going to be out of town Sunday and Monday, I'll sing Happy Birthday to you today. Turn on your speakers and click the .mp3 link, and, the 4 Big Bobs will serenade you.

http://www.andrewkmusic.com/filearea/SI ... rthday.mp3


----------



## mbncp (Jul 14, 2007)

> I think I'm almost beginning to understand it


You got it 5/5, and nicely summarized.



> Nils kindly added C-style hex number input to his KScript Editor?


I still have to check all features of Nil’s editor. I didn’t try functions and families yet, but also I didn’t do much with KSP so far. Time for a change 



> Turn on your speakers


Thanks :D

And take some rest Bob, I think we’ve been over doing it lately. When I “write” code while sleeping, I know that I exaggerated, again .. :lol: 

Cheers,
Marc


----------



## JustinW (Jul 14, 2007)

If I am understanding what I am reading correctly, this would make my year. I am very interested in setting up the 64 instrument multi for K2 whilst using it as a VST plug.

From what I gather; Marc, you stated, that the DL you linked was not intended for the 64 patches, but I eagerly await its arrival.

I wish had some useful information to input, but I am sorry to say, I do not. But thank you man, this will be groundbreaking.


----------



## mbncp (Jul 15, 2007)

> I am very interested in setting up the 64 instrument multi for K2 whilst using it as a VST plug.


Hi Justin,
This is already possible with the current version. I just didn't include, yet, the script that can deal with multi channel info in KSP (very special stuff).

Anyway, I would wait a little, as I didn't fully tested all this and there are already some changes(plug and script).
Updating a script in 64 instruments is not exactly what I call great fun  
Also, I still have to check the extra CPU needed by all this. Normally it should be insignificant, but I need a clear picture.

Cheers,
Marc


----------



## mbncp (Jul 26, 2007)

Hi all, 
some bad news ahead.
As I already told Bob, the extra time used by K2 when receiving these extra notes is enormous.
I made a test, sending 10 notes per port to 4 different instruments, all using the script and sending the encoded events on a single channel, the script rejecting events from other ports.
Then I did it normally, without the plug and script, using 4 different channels.

In both case, K2 would play 40 voices. The average for note on (and note off) was *1.2 msec* without the script and encoded events, while it was over *10 msec *with the encoded events and the script.

Off course I wanted to check if it was due to my plug, and replaced k2 with just another instance of the plug, and there the difference is about 80 microseconds (0.08 msec).

And this is with K2.2.3 :( 

I really have no idea why k2 takes so much time with note events. At least until the event made it thru all script slots, I don't think that k2 should do anything special.

Anyway, instead of loosing my time ( and others) to overcome k2 limitations, waiting for a fix and features that may never come, I finally started to write my own sampler. 
I just can't beleive that we still can't use sample start offset in DFD mode.

Sorry for the bad hopes, but this is totally unusable.

Cheers,
Marc


----------



## Big Bob (Jul 26, 2007)

Hey Marc,

I'm really sorry to hear that K2.2.3 didn't improve things any, I was kind of hoping it would. Since your main interest with doing this plugin and script was to gain the multiport/multichannel benefit, I can understand why you are completely discouraged.

However, the prospect of you writing a sampler that will do things right is certainly exciting to contemplate :o I'm sure everyone on this forum would like you to keep them posted as to your progress with this project. 8) 

But, in the meantime (so that all is not lost), I think a less-ambitious version of your plugin and script would still be quite useful and would be much appreciated by the K2 community. As you probably know, I already added Aftertouch to the MIDI CC menus for the newest version of SIPS (on the assumption that your plugin would be available to provide the NRPN messages). Also, the KSP Timer function is very useful, not only for the ISCS startup and loop-maintenence functions, but also for smoothly-flashing messages, etc. So while the rest of it didn't come up to your expectations, I think a subset of what you have done would still be very useful.

So, I hope you will still consider 'donating' your plugin and and a scaled-down version of the slot-1 script to the community. I would be glad to write and maintain the script part of the thing but of course I would need to use your plugin to make it work. If I remember correctly, you were adding some options to the version of the plug that you gave me for testing (to allow enabling/disabling which messages the plug would generate). Did you ever finish that and if so, would you mind making it (or perhaps some other scaled-down version) available to us so we could at least use it for things like AT, Prog Change, and the KSP Timer function?

BTW Marc, have you gotten your new computer up yet? If so, what did you end up with?

God Bless,

Bob


----------



## mbncp (Jul 27, 2007)

Hi Bob,



> However, the prospect of you writing a sampler that will do things right is certainly exciting to contemplate :o I'm sure everyone on this forum would like you to keep them posted as to your progress with this project. 8)


Don't know where I'm going with this, maybe just a good excuse to have some fun with dsp. One of my biggest frustration with current commercial samplers is the close file format.
Well ..



> So, I hope you will still consider 'donating' your plugin and a scaled-down version of the slot-1 script to the community. I would be glad to write and maintain the script part of the thing but of course I would need to use your plugin to make it work. If I remember correctly, you were adding some options to the version of the plug that you gave me for testing (to allow enabling/disabling which messages the plug would generate). Did you ever finish that and if so, would you mind making it (or perhaps some other scaled-down version) available to us so we could at least use it for things like AT, Prog Change, and the KSP Timer function?



Yes, sorry, but I was too tired and depressed to speak about it last night :mrgreen: 
What I've been thinking is to totally remove the special encoding thingy as this is obviously taking too much resources.
I would keep the timer as is and add a "Convert to CC" option for patch change and channel aftertouch. This way we don't even have to insert a special script to use aftertouch or patch change within KSP.
What do you think ?



> BTW Marc, have you gotten your new computer up yet? If so, what did you end up with?


Yeap :D Received everything this morning and started to build the all thing this afternoon. Currently formatting the drives ..................................... 

I have to say that I went a little whacko when I made my order.
A Q6600 processor (couldn't resist the price drop this monday), 4 GB of Ram (800/4-4-4-12), 2x 1000GB drives, a fancy mobo and a graphic card with dual DVI output (this thing is almost one foot long :roll: )


Cheers,
Marc


----------



## Big Bob (Jul 27, 2007)

Hi Marc,



> Yes, sorry, but I was too tired and depressed to speak about it last night



Now don't let it get you down my friend, this too shall pass :wink: . However, I'm glad you got your new computer this morning because I bet that pulled you out of the doldrums :D 



> I would keep the timer as is and add a "Convert to CC" option for patch change and channel aftertouch. This way we don't even have to insert a special script to use aftertouch or patch change within KSP.
> What do you think ?



That's fine with me Marc. The only thing I would ask is that the "Convert to CC" feature should generate NRPN events (as it is now with the script) instead of converting AT and PC to standard CC#s. Just let me know when you get it ready and I'll take it for a test spin. 8) 



> I have to say that I went a little whacko when I made my order.
> A Q6600 processor (couldn't resist the price drop this monday), 4 GB of Ram (800/4-4-4-12), 2x 1000GB drives, a fancy mobo and a graphic card with dual DVI output (this thing is almost one foot long )



Wow! That does sound mouth watering, and one terrabyte hard drives yet :shock: (in the mid-80s when a 10MB hard drive was a big deal, who would have ever thought that we'd live to see 1TB drives? :o ). But then, sometimes it's fun to go 'a little whacko' so I'm very happy for you.

God Bless,

Bob


----------



## mbncp (Jul 28, 2007)

Hi Bob,



> The only thing I would ask is that the "Convert to CC" feature should generate NRPN events (as it is now with the script) instead of converting AT and PC to standard CC#s


Sending NRPN to K2 is pretty buggy.

When changing the NRPN value K2 will generate an nrpn and when changing the value k2 will also generate an nrpn.
so if you send:
nrpn 1234 = 512
followed by
nrpn 4567 = 1024
the second time, K2 will generate 3 nrpn events:

nrpn 1234 = 1024 {bug}
nrpn 1234 = 512
nrpn 4567 = 1024

There are also other issues where sometimes I don't get the nrpn, weird coding :roll: 

Btw, do you know if there is a way to receive all cc messages in k2 ? If I send the same CC with different values at the same time, only the last one makes it to ksp.

Cheers,
Marc


----------



## Big Bob (Jul 28, 2007)

Hi Marc,



> There are also other issues where sometimes I don't get the nrpn, weird coding



Oh my, I'm sorry to hear that. :( More KSP bumps in the night? I wonder if it could be timing related?

For example, I know that if I generate a series of CC messages such as:

CC98 followed quickly by CC99, the KSP always produces two CCBs with CC_NUM = 98 followed by CC_NUM = 99. When I say quickly I mean keyboard-finger quickly. So I assume that K2 will interpret the NRPN series and trigger an NRPN callback only if the individual CC events are very tightly packed? (perhaps along with the CC38 and CC6 data set). I assume you are 'piecing together' the NRPN by generating the series CC98,CC99,CC38,CC6 back to back? 

Have you tried sending CC38,CC6 with the RPN 'null value' set to 0x7F, 0x7F *after you send the desired data? *For example, send NRPN 1234 = 512 then send 16383 for data? I know that some synths like to receive 16383 after a series of data values before changing the NRPN number. Just a shot in the dark but it probably wouldn't hurt to try it.



> Btw, do you know if there is a way to receive all cc messages in k2 ? If I send the same CC with different values at the same time, only the last one makes it to ksp.



I suspect that K2 only uses a 128-element array (the %CC array) to hold the last value of each CC. If this is the case, then the only way to get them all would be to separate them in time. The way it is (if my assumption is correct), you can't send a new value until you read the old value in the CC array. Otherwise the new value clobbers the prior value before you can read it.

In any case, if you can't map AT and PC directly to NRPNs and you are thinking instead of mapping them to regular CCs, I think I would almost prefer to have you encode them as subsonic notes (perhaps in a simpler way than with the MPSC). Or at least make that an option. Of course we would then need a script in slot 1 to decode these events but I'm pretty sure I'd like to put a script in that slot anyway. So, the decoding of AT and PC messages need only be a small part of what the slot-1 script does. We might also include something for articulation switching and/or repetition effects such as the UTKT, etc. In fact, for those who don't want (or can't) use a plugin, I've written a small script to provide ISCS 'starter' and KSP-Timer functions. This script also generates a uniform 100ms CC119 clock which automatically detects the plugin Timer and switches to it when it's present. We could simply embellish this 'starter' script to contain the AT, PC decoder and whatever other miscellaneous functions we might want to add later.

So I guess my first choice would be to map AT and PC to NRPN (if possible reliably). My second choice would be to provide two forms of mapping. The first option would be to map AT and PC to subsonic notes 1 and 2 (carrying the data in the velocity byte). The second option would be to simply map AT and PC to a pair of selectable CCs. This 2nd option would then allow the Plug to work without a Slot-1 Script (provided the user is willing to dedicate a pair of CCs for this purpose). On the other hand, using the 1st option with a special Slot-1 Script would allow AT and PC to be mapped to NRPNs. What do you think?

God Bless,

Bob

BTW When I use the term AT, I am of course refering to Mono Aftertouch/Channel Pressure as opposed to Poly Aftertouch/Key Pressure (I understand that very few keyboards support Poly AT).


----------



## Big Bob (Aug 8, 2007)

Hey Marc,

Have you come to any conclusions on this yet?

God Bless,

Bob


----------



## mbncp (Aug 11, 2007)

Hi Bob,

It's vacation times over here, well at least for my nephew :lol: 

I will try to finish setting up the dev tools on my new machine next week and do some more testing. Let you know.

Cheers,
Marc


----------



## Big Bob (Aug 11, 2007)

Hey Marc,

Good to hear from you. In fact I just sent you an email (which you can now ignore :D ).

God Bless,

Bob


----------

