storyteller
Senior Member
Ha, Lightsabers were apparently drawn at some point...
btw - I love the people involved in the dual though... So... Carry On.
Ha, Lightsabers were apparently drawn at some point...
I understand SublimeKSP could be too bothersome to learn (especially with its fragmented doc), especially if your projects are simple enough to dispense with it. But for what I've been tackling, I could hardly do without the comforts of its features making KSP at least half resemble a modern language. It has been a lifesaver in some situations.Somehow I find KSP much simpler and comfortable than SublimeKSP, I really hate what I have to deal with it, it's like adding layers of nonsense to something that is already convoluted enough.
I don't think it's complexity that matters here, I believe I have been dealing with fairly complex stuff (as far as Kontakt goes), maybe not, I don't know what are you dealing with. Anyway, what I meant, it's mainly a frame of mind problem. What I see, is that people who already program in some language seem to hate KSP when they are exposed to it. I had little programing experience prior to KSP and that was in 8 bit some long time ago, which is possibly why I have no discomfort here.I understand SublimeKSP could be too bothersome to learn (especially with its fragmented doc), especially if your projects are simple enough to dispense with it.
If KSP is unnecessarily terse
define NUM_SLIDERS := 10
declare ui_slider Slider[NUM_SLIDERS] (0, 1000000)
declare ui_slider $Slider0 (0, 1000000)
declare ui_slider $Slider1 (0, 1000000)
declare ui_slider $Slider2 (0, 1000000)
declare ui_slider $Slider3 (0, 1000000)
declare ui_slider $Slider4 (0, 1000000)
declare ui_slider $Slider5 (0, 1000000)
declare ui_slider $Slider6 (0, 1000000)
declare ui_slider $Slider7 (0, 1000000)
declare ui_slider $Slider8 (0, 1000000)
declare ui_slider $Slider9 (0, 1000000)
ordering of CC-note-CC-note-CC-note
Especially since Nil's approach is basically a pre-processor that produces KSP, I feel its important to understand even the generated KSP. There are always pros and cons to using a higher level language that generates a lower level language. It can make some things easier and some things more difficult. I say that in complete ignorance about both KSP and Nil's stuff, but extensive experience as a software developer that has had to deal with various kinds of preprocessors over the years. They can be a blessing and/or a curse.
On script level events appear in host programmed order, so if you script automation it may solve the problem.
It quite is
Would you rather write:
Code:define NUM_SLIDERS := 10 declare ui_slider Slider[NUM_SLIDERS] (0, 1000000)
or:
Code:declare ui_slider $Slider0 (0, 1000000) declare ui_slider $Slider1 (0, 1000000) declare ui_slider $Slider2 (0, 1000000) declare ui_slider $Slider3 (0, 1000000) declare ui_slider $Slider4 (0, 1000000) declare ui_slider $Slider5 (0, 1000000) declare ui_slider $Slider6 (0, 1000000) declare ui_slider $Slider7 (0, 1000000) declare ui_slider $Slider8 (0, 1000000) declare ui_slider $Slider9 (0, 1000000)
So KSP multi-script could access the automatable parameters of a commercial sample instrument, same as Kontakt's CC automation does?
Anyway, one reason I find KSP tedious is because of how strict it is when it comes to types, and it pains me how simple formulaes become unreadable when you nest int_to_real's into real_to_int's...
{x}%records[%rec_str[0] + $count + %rec_offset[$count2]] := real_to_int((0.50 + (int_to_real($radius) / 1000.0) * sin(~NI_MATH_PI * int_to_real($count) / int_to_real($pb_bars * $BAR_LENGTH) * int_to_real($pb_bars) * 2.0 - ~NI_MATH_PI / 2.0)) * 1000.0)
{y}%records[%rec_str[0] + $REC_MAX + $count + %rec_offset[$count2]] := abs(real_to_int((0.50 + (int_to_real($radius) / 1000.0) * cos(~NI_MATH_PI * int_to_real($count) / int_to_real($pb_bars * $BAR_LENGTH) * int_to_real($pb_bars) * 2.0 - ~NI_MATH_PI / 2.0)) * 1000.0))
Not really, multiscript can only process MIDI stream. So you would have change/add code at instrument level to make CC interact with given parameter. If it's commercial lib, hard luck as the script is most likely locked.
You can load factory MIDI monitor script into empty instrument and see that the event queue is preserved. It is for me, feeding from Sonar to Kontakt 5.
What are you trying to achieve? Microtuning by chance?
LogicPro scripts to send that CC per articulationID when needed...
On one hand, I can respect that, as it's been my own stance more than once.I don't think it's complexity that matters here, I believe I have been dealing with fairly complex stuff (as far as Kontakt goes), maybe not, I don't know what are you dealing with. Anyway, what I meant, it's mainly a frame of mind problem. What I see, is that people who already program in some language seem to hate KSP when they are exposed to it. I had little programing experience prior to KSP and that was in 8 bit some long time ago, which is possibly why I have no discomfort here.
That's definitely right.Especially since Nil's approach is basically a pre-processor that produces KSP, I feel its important to understand even the generated KSP.
Yes of course.Question for you. If you use the declare macro above...can you later in the script refer to $Slider1 directly even though you never actually coded a declare for that control yourself?
Question for you. If you use the declare macro above...can you later in the script refer to $Slider1 directly even though you never actually coded a declare for that control yourself?
define NUM_SLIDERS := 10
declare ui_slider Slider[NUM_SLIDERS] (0, 1000000)
Slider6 := 100
KSP multi-script...is that before CC automation also?
And presumably kontakt processes cc automation once per process block...
I think you could write $Slider[1] (as in first element of an array)
I guess another question would be this...KSP multi-script...is that before CC automation also?
on init
set_script_title("force schedule")
{
detect events that occur within given frame (value in milliceconds - 1/1000 s),
delay all events that occur within the timeframe by defined delay (value in microseconds = 1/1000000),
second event receives double delay, third received tripple delay and so on...
}
declare ui_value_edit $delay(100,5000,1)
declare ui_value_edit $frame(1,200,1)
declare ui_button $on
$delay := 500
declare $x
declare $event_counter
declare $time_checkpoint
make_persistent($delay)
make_persistent($frame)
make_persistent($on)
end on
on midi_in
if($on =1)
if($MIDI_COMMAND = $MIDI_COMMAND_NOTE_OFF or $MIDI_COMMAND = $MIDI_COMMAND_NOTE_ON or $MIDI_COMMAND = $MIDI_COMMAND_CC) {only process notes and CC}
$x := $ENGINE_UPTIME - $time_checkpoint {how much time passed from last event?}
if($x <= $frame) {not enough, delay event}
inc($event_counter)
ignore_midi
wait($delay * $event_counter)
set_midi($MIDI_CHANNEL,$MIDI_COMMAND,$MIDI_BYTE_1,$MIDI_BYTE_2)
else
$time_checkpoint := $ENGINE_UPTIME
$event_counter := 0
end if
end if
end if
end on