Menu
▾
▴
linuxsampler-devel
|
From: Andrew C <cou...@gm...> - 2017-05-23 22:14:30
|
So I have the Bb Clarinet long notes file mostly working out of the box. Normal sustain/staccato programs work fine. The X-fade instruments work fine. The basic No Vibrato/Vibrato keyswitch instruments work fine. *The sustain/attack mod wheel instruments need the attack attenuation controller set to Modwheel 1 in gigedit for the attack sample intensity via modwheel to work properly. *Glissando/Legato instruments (using the imidi legato rules and smartmidi dimensions) are very buggy/broken: The lowest note in the instrument's range is silent and just 'clicks' when activated. The adjacent C# appears to be programmed exactly the same way but sound is heard(see below). The notes above C4 or so are 'clicky' too for no apparent reason. When playing the notes that do work, only the initial attack and the sustain sample is heard, moving in a legato manner up/down the keyboard does not work. I'm not sure if the developers want to troubleshoot this for a single unique giga file? AFAICS, the imidi stuff is deprecated basically in favour of the kontakt scripting (which'd make a lot more sense, but would require reprogramming the entire legato instrument from the sample level up), but there is not (yet) a working proof of concept of these rules working in a gig file under LinuxSampler. Andrew. |
|
From: Andrew C <cou...@gm...> - 2017-05-23 22:24:05
|
Hope this didn't come across as presumptous/demanding.. Just slightly excited at the prospect of in-engine legato being a reality in LinuxSampler from a design POV. Just seems really cool if it could be done and work. On Tue, May 23, 2017 at 11:14 PM, Andrew C <cou...@gm...> wrote: > So I have the Bb Clarinet long notes file mostly working out of the box. > > Normal sustain/staccato programs work fine. > The X-fade instruments work fine. > The basic No Vibrato/Vibrato keyswitch instruments work fine. > > *The sustain/attack mod wheel instruments need the attack attenuation > controller set to Modwheel 1 in gigedit for the attack sample intensity via > modwheel to work properly. > > *Glissando/Legato instruments (using the imidi legato rules and smartmidi > dimensions) are very buggy/broken: > > The lowest note in the instrument's range is silent and just 'clicks' when > activated. > The adjacent C# appears to be programmed exactly the same way but sound is > heard(see below). > The notes above C4 or so are 'clicky' too for no apparent reason. > When playing the notes that do work, only the initial attack and the > sustain sample is heard, moving in a legato manner up/down the keyboard > does not work. > > I'm not sure if the developers want to troubleshoot this for a single > unique giga file? > > AFAICS, the imidi stuff is deprecated basically in favour of the kontakt > scripting (which'd make a lot more sense, but would require reprogramming > the entire legato instrument from the sample level up), but there is not > (yet) a working proof of concept of these rules working in a gig file under > LinuxSampler. > > Andrew. > |
|
From: Christian S. <sch...@li...> - 2017-05-24 10:53:13
|
On Tuesday, May 23, 2017 23:14:23 Andrew C wrote: > *Glissando/Legato instruments (using the imidi legato rules and smartmidi > dimensions) are very buggy/broken: > > The lowest note in the instrument's range is silent and just 'clicks' when > activated. > The adjacent C# appears to be programmed exactly the same way but sound is > heard(see below). > The notes above C4 or so are 'clicky' too for no apparent reason. > When playing the notes that do work, only the initial attack and the > sustain sample is heard, moving in a legato manner up/down the keyboard > does not work. Like I said, the legato iMIDI rules are currently simply ignored by the sampler. What happens is that the sampler currently just plays the sample of the very first dimension region zone of the "smart midi" dimension. In gigedit that's the most left dimension region zone of the "smart midi" dimension. > I'm not sure if the developers want to troubleshoot this for a single > unique giga file? Well, I can just speak for myself of course; unfortunately I am personally not interested in implementing Tascam's legato iMIDI rules in LS for the reasons said before. Scripts do much more than those, and the scripting power is growing every day. But if somebody wants to implement those legato rules; go ahead, you have the sources, and on gigedit and libgig side they are already implemented. > AFAICS, the imidi stuff is deprecated basically in favour of the kontakt > scripting (which'd make a lot more sense, but would require reprogramming > the entire legato instrument from the sample level up), but there is not > (yet) a working proof of concept of these rules working in a gig file under > LinuxSampler. You are just calling play_note() based on a) which key was previously pressed down and b) which new key was pressed down (see %KEY_DOWN[] and $EVENT_NOTE): http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/play_note_function/ Everything you do beyond that in your script, is more what those original legato iMIDI rules were able to do. It really works. But sure, there is probably no ready-to-use example script yet that you could simply copy and paste specifically for legato. So yes, you would need to read the scripting docs, write some script by yourself and create your own instrument preset with either gigedit or a SFZ file to resemble the legato behavior with the legato samples your already have there. CU Christian |
|
From: Andrew C <cou...@gm...> - 2017-05-24 14:30:23
|
Thanks for the info there, Christian. Having a pretty good time exploring
NKSP right now.
Before I try the legato, I'm trying to give an alternation script a go.
One question, how does "ignore_event" work? I RTFM and it says it can be
used to ignore MIDI note-on and note-off commands before they're triggered.
I would imagine this *should* make the current note in $EVENT_ID not be
played, but when I click on the piano in gigedit/jsampler, the note plays
anyway.
note_off($EVENT_ID) in a "on note" block causes linuxsampler to segfault
too. :\
Here's my code for the alternation script so far:
on init
declare polyphonic $alt
end on
on note
ignore_event($EVENT_ID)
message("Alternation number is: " & $alt)
select $alt
case 0
play_note($EVENT_NOTE, $EVENT_VELOCITY)
message("upbow")
$alt := 1
case 1
play_note($EVENT_NOTE+36, $EVENT_VELOCITY)
message("downbow")
$alt := 0
end select
end on
|
|
From: Christian S. <sch...@li...> - 2017-05-24 20:10:08
|
On Wednesday, May 24, 2017 15:30:12 Andrew C wrote: > One question, how does "ignore_event" work? I RTFM and it says it can be > used to ignore MIDI note-on and note-off commands before they're triggered. > I would imagine this *should* make the current note in $EVENT_ID not be > played, but when I click on the piano in gigedit/jsampler, the note plays > anyway. > > note_off($EVENT_ID) in a "on note" block causes linuxsampler to segfault > too. :\ I haven't tried your script yet. However I just fixed a bunch of event scheduling bugs which might potentially be related to what you encountered. So please update LS to latest SVN and try again. If the script still does not work as expected, let me know! CU Christian |
|
From: Andrew C <cou...@gm...> - 2017-05-24 21:13:45
|
Just updated to the latest and it works (ignoring event_id ignores input).
Just having a logic problem in my script (My issue, not the sampler)
When I put in the full parameters for play_note and tell it to keep the
same note_off value for the original note, in 'case 0', the $event_note is
played correctly, but in 'case 1', the $event_note and $event_note + 5 get
played the same time. I thought I had told ignore_event to ignore the
initial note?
If I ignore event_id, the whole instrument because silent (well, this is
the correct behaviour of course :D )
--
On a related note, it seems that 'change_note' in ksp could achieve the
desired effect of transposing incoming notes:
"The values of $EVENT_NOTE and $EVENT_VELOCITY can be changed by using the
following functions:
change_note(<ID-number>,<new-note-number>)
change the note value of a specific note event
change_velo(<ID-number>,<new-velocity-number>)
change the velocity value of a specific note event"
Andrew.
on init
declare polyphonic $alt
end on
on note
ignore_event($EVENT_NOTE)
message("Alt is: " & $alt)
select $alt
case 0
play_note($EVENT_NOTE, $EVENT_VELOCITY, 0, -1)
message("Root note")
$alt := 1
case 1
play_note($EVENT_NOTE+5, $EVENT_VELOCITY, 0, -1)
message("Transposed")
$alt := 0
end select
end on
On Wed, May 24, 2017 at 9:12 PM, Christian Schoenebeck <
sch...@li...> wrote:
> On Wednesday, May 24, 2017 15:30:12 Andrew C wrote:
> > One question, how does "ignore_event" work? I RTFM and it says it can be
> > used to ignore MIDI note-on and note-off commands before they're
> triggered.
> > I would imagine this *should* make the current note in $EVENT_ID not be
> > played, but when I click on the piano in gigedit/jsampler, the note plays
> > anyway.
> >
> > note_off($EVENT_ID) in a "on note" block causes linuxsampler to segfault
> > too. :\
>
> I haven't tried your script yet. However I just fixed a bunch of event
> scheduling bugs which might potentially be related to what you
> encountered. So
> please update LS to latest SVN and try again. If the script still does not
> work as expected, let me know!
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
|
|
From: Christian S. <sch...@li...> - 2017-05-24 21:57:34
|
On Wednesday, May 24, 2017 22:13:38 Andrew C wrote:
> Just updated to the latest and it works (ignoring event_id ignores input).
> Just having a logic problem in my script (My issue, not the sampler)
>
> When I put in the full parameters for play_note and tell it to keep the
> same note_off value for the original note, in 'case 0', the $event_note is
> played correctly, but in 'case 1', the $event_note and $event_note + 5 get
> played the same time. I thought I had told ignore_event to ignore the
> initial note?
[snip]
> on init
> declare polyphonic $alt
> end on
>
> on note
> ignore_event($EVENT_NOTE)
>
> message("Alt is: " & $alt)
>
> select $alt
>
> case 0
> play_note($EVENT_NOTE, $EVENT_VELOCITY, 0, -1)
> message("Root note")
> $alt := 1
> case 1
> play_note($EVENT_NOTE+5, $EVENT_VELOCITY, 0, -1)
> message("Transposed")
> $alt := 0
> end select
>
> end on
Your variable $alt is declared "polyphonic". That means each time your note
event handler is executed, it is using a completely separate instance of your
variable $alt (which is always initialized with 0 by the way). Hence $alt is
always 0 and thus your case 1 is never executed.
Just remove keyword "polyphonic" and it will probably behave as you intended
it to do.
http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/#polyphonic_variables
The value of polyphonic variables is only preserved from a note handler to its
(own) release handler. So you can use polyphonic variables to "stick" your own
custom values to one specific note if your will.
> On a related note, it seems that 'change_note' in ksp could achieve the
> desired effect of transposing incoming notes:
>
> "The values of $EVENT_NOTE and $EVENT_VELOCITY can be changed by using the
> following functions:
>
> change_note(<ID-number>,<new-note-number>)
>
> change the note value of a specific note event
>
> change_velo(<ID-number>,<new-velocity-number>)
> change the velocity value of a specific note event"
Correct, that's what you rather wanted to do in your example instead. Right
now your can use set_event_par() instead:
http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/set_event_par_function/
I will certainly also add change_vol() and change_note() just for sake of
completeness. The behavior is absolutely identical though.
ATM you can even do that:
$EVENT_NOTE := 40
$EVENT_VELOCITY := 127
But I am not sure yet whether that will change in future, maybe those will
become read-only variables one day, so writing to those built-in variables is
currently not a documented behavior, and probably you are not allowed to do
that with KSP at all.
CU
Christian
|
|
From: Andrew C <cou...@gm...> - 2017-05-25 11:28:58
|
Thanks for that update, Christian and for dealing with my inane feedback.
Got a compile error on the latest cvs release:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -Wreturn-type
-ffast-math -g -O2 -pthread -MT parser.lo -MD -MP -MF .deps/parser.Tpo -c
parser.cpp -fPIC -DPIC -o .libs/parser.o
In file included from parser_shared.h:16:0,
from parser.y:14:
tree.h: In member function ‘virtual void
LinuxSampler::ExecContext::resetPolyphonicData()’:
tree.h:715:84: error: ‘memset’ was not declared in this scope
memset(&polyphonicIntMemory[0], 0, polyphonicIntMemory.size() *
sizeof(int));
^
Makefile:532: recipe for target 'parser.lo' failed
make[5]: *** [parser.lo] Error 1
make[5]: Leaving directory
'/home/andrew/Desktop/Linuxsampler/linuxsampler/src/scriptvm'
Andrew.
On Thu, May 25, 2017 at 12:17 PM, Christian Schoenebeck <
sch...@li...> wrote:
> On Thursday, May 25, 2017 04:29:01 you wrote:
> > > Your variable $alt is declared "polyphonic". That means each time your
> > > note
> > > event handler is executed, it is using a completely separate instance
> of
> > > your
> > > variable $alt (which is always initialized with 0 by the way). Hence
> $alt
> > > is
> > > always 0 and thus your case 1 is never executed.
> >
> > Actually, with the above script, case 1 is executed if i press the same
> key
> > multiple times, or other keys multiple times on a per note basis. Cool
> > stuff :D
>
> You actually found a bug. The polyphonic data was not reset to zero. I
> never
> stumbled over this bug since so far I always initialized polyphonic
> variables
> with some data at the beginning of the event handler like:
>
> on init
> declare polyphonic $foo
> end on
>
> on note
> $foo := 4
> ...
> end on
>
> I just fixed that bug now. They are now automatically reset to 0.
>
> However the rest of what I said about polyphonic variables was true. In
> your
> case you were just "lucky" that the exact same memory portion was used for
> the
> polyphonic variable, which was due to the fact that your script was quite
> simple and only one event handler instance was executed at a time. For
> example
> the following simple script:
>
> on init
> declare polyphonic $foo
> end on
>
> on note
> { increment variable by 1 }
> inc($foo)
> { print value to terminal }
> message("foo is " & $foo)
> { sleep for 3 seconds }
> wait(3000000)
> end on
>
> Would have behaved differently there when you trigger multiple notes in
> short
> time. Because with that example (due to the wait() call) several instances
> of
> the event handler would have been executed, each one with its own $foo
> variable instance.
>
> > The case logic works, but yeah, the benefit of having a 'per key'
> > transposition is up for debate.. Unless I'm doing avant-garde! :D
>
> Like I said, you would not use a polyphonic variable for your specific
> example. And if you wanted a alternating value per key, you would do it
> with
> array variable instead:
>
> on init
> declare %alt[128] { not polyphonic ! a global, shared array variable }
> end on
>
> on note
> ...
> %alt[$EVENT_NOTE] := 0
> ...
> %alt[$EVENT_NOTE] := 1
> ...
> end on
>
> > Just to better highlight the issue I'm having with the above script, I
> > wrote this small snippet:
> >
> > on note
> > ignore_event($EVENT_NOTE)
> > ignore_event($EVENT_VELOCITY)
>
> That's not how ignore_event() works. ignore_event() expects an "event ID".
> An
> event ID is neither a MIDI note number, nor a MIDI velocity value, an
> event ID
> is like a sampler internal time stamp which identifies exactly one specific
> event in time. So usually you call ignore_event() like this:
>
> ignore_event($EVENT_ID)
>
> $EVENT_ID is a built-in variable reflecting the event which cause the
> current
> event handler to be executed. So in a note handler it is the event ID of
> the
> note-on event, in a release handler it is the event id of the note-off
> event,
> in a controller handler it is the event ID of the MIDI CC event, etc.
>
> Maybe I have to make that more clear in the docs of that function.
>
> CU
> Christian
>
|
|
From: Christian S. <sch...@li...> - 2017-05-25 11:45:41
|
On Thursday, May 25, 2017 12:28:50 Andrew C wrote: > Thanks for that update, Christian and for dealing with my inane feedback. > > Got a compile error on the latest cvs release: Ok, our repository server is old, but not *that* old. ;-) It's svn (Subversion server). > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -Wreturn-type > -ffast-math -g -O2 -pthread -MT parser.lo -MD -MP -MF .deps/parser.Tpo -c > parser.cpp -fPIC -DPIC -o .libs/parser.o > In file included from parser_shared.h:16:0, > from parser.y:14: > tree.h: In member function ‘virtual void > LinuxSampler::ExecContext::resetPolyphonicData()’: > tree.h:715:84: error: ‘memset’ was not declared in this scope > memset(&polyphonicIntMemory[0], 0, polyphonicIntMemory.size() * > sizeof(int)); > > ^ > Makefile:532: recipe for target 'parser.lo' failed > make[5]: *** [parser.lo] Error 1 I just fixed it. Should work now. CU Christian |
|
From: Andrew C <cou...@gm...> - 2017-05-25 17:56:18
|
Fantastic, I'm getting closer. :) I hadn't realised that set_event_par changes the voice data itself though. But I'm probably misunderstanding alot of nksp's terminology. I was expecting to actually change the incoming midi note itself, not transpose the voice data. i.e: set_event_par($EVENT_ID, $EVENT_PAR_NOTE, $EVENT_NOTE+36) // - Chipmunk effect, not a new note-on. :( On Thu, May 25, 2017 at 12:48 PM, Christian Schoenebeck < sch...@li...> wrote: > On Thursday, May 25, 2017 12:28:50 Andrew C wrote: > > Thanks for that update, Christian and for dealing with my inane feedback. > > > > Got a compile error on the latest cvs release: > > Ok, our repository server is old, but not *that* old. ;-) It's svn > (Subversion > server). > > > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -Wreturn-type > > -ffast-math -g -O2 -pthread -MT parser.lo -MD -MP -MF .deps/parser.Tpo -c > > parser.cpp -fPIC -DPIC -o .libs/parser.o > > In file included from parser_shared.h:16:0, > > from parser.y:14: > > tree.h: In member function ‘virtual void > > LinuxSampler::ExecContext::resetPolyphonicData()’: > > tree.h:715:84: error: ‘memset’ was not declared in this scope > > memset(&polyphonicIntMemory[0], 0, polyphonicIntMemory.size() * > > sizeof(int)); > > > > ^ > > Makefile:532: recipe for target 'parser.lo' failed > > make[5]: *** [parser.lo] Error 1 > > I just fixed it. Should work now. > > CU > Christian > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Andrew C <cou...@gm...> - 2017-05-25 18:19:48
|
I'd consider the 'correct' behaviour of change_note/set_event_par to be to change the incoming midi note data itself, as opposed to the voice data, but the use of the two in tandem could give interesting results. Could I suggest an extension of change_note, an optional argument to change the voice data itself and/or the incoming midi data? This might be silly feature creep though. |
|
From: Christian S. <sch...@li...> - 2017-05-25 18:43:42
|
On Thursday, May 25, 2017 19:19:40 Andrew C wrote: > I'd consider the 'correct' behaviour of change_note/set_event_par to be to > change the incoming midi note data itself, as opposed to the voice data, > but the use of the two in tandem could give interesting results. > Could I suggest an extension of change_note, an optional argument to change > the voice data itself and/or the incoming midi data? > This might be silly feature creep though. I think I already addressed that today (as I was already at it when I added change_velo() and change_note() today). After you updated LS to latest SVN it should apply the note/velocity changes to the MIDI event as well as to the voices, so it should behave as expected by you. Which is a substantial behavior difference of course, since other samples would be triggered, mickey mouse effect, etc. I am actually not sure what the precise behavior of Kontakt is on that issue. I guess it also modifies the MIDI event directly, but not sure. Fact is Kontakt has two separate levels of event handling by scripts. One level are the event handlers which we also have right now in LS. Then they also have another raw MIDI event handler level called "Multi Script", which is modifying the raw MIDI data itself before it is actually passed to that 2nd level we have. That raw MIDI handling level of KSP has exactly one event handler: on midi_in ... end on It allows you to modify MIDI events, drop MIDI events and create completely new MIDI events on your own by script. ATM we don't have that event handler (and thus this first level of raw MIDI processing) yet. Mainly because so far I saw no huge benefit of having it. But who knows, maybe I am also missing out a killer use case for that layer. CU Christian |
|
From: Andrew C <cou...@gm...> - 2017-05-25 19:34:44
|
>After you updated LS to latest SVN it >should apply the note/velocity changes to the MIDI event as well as to the >voices, so it should behave as expected by you. Well, I updated to the latest svn, but the MIDI data itself doesn't change with change_note unfortunately, only the voice data. i.e chipmunk effect occurs if I transpose C3 up to C4 using change_note, rather than triggering the C4. :S >ATM we don't have that event handler (and thus this first level of raw MIDI >processing) yet. Mainly because so far I saw no huge benefit of having it. But >who knows, maybe I am also missing out a killer use case for that layer. I can dig that. From what I read of other Kontakt scripts, the multiscript stuff is mainly used for channel switching tricks, etc. On Thu, May 25, 2017 at 7:46 PM, Christian Schoenebeck < sch...@li...> wrote: > On Thursday, May 25, 2017 19:19:40 Andrew C wrote: > > I'd consider the 'correct' behaviour of change_note/set_event_par to be > to > > change the incoming midi note data itself, as opposed to the voice data, > > but the use of the two in tandem could give interesting results. > > Could I suggest an extension of change_note, an optional argument to > change > > the voice data itself and/or the incoming midi data? > > This might be silly feature creep though. > > I think I already addressed that today (as I was already at it when I added > change_velo() and change_note() today). After you updated LS to latest SVN > it > should apply the note/velocity changes to the MIDI event as well as to the > voices, so it should behave as expected by you. Which is a substantial > behavior difference of course, since other samples would be triggered, > mickey > mouse effect, etc. > > I am actually not sure what the precise behavior of Kontakt is on that > issue. > I guess it also modifies the MIDI event directly, but not sure. > > Fact is Kontakt has two separate levels of event handling by scripts. One > level are the event handlers which we also have right now in LS. Then they > also have another raw MIDI event handler level called "Multi Script", > which is > modifying the raw MIDI data itself before it is actually passed to that 2nd > level we have. That raw MIDI handling level of KSP has exactly one event > handler: > > on midi_in > ... > end on > > It allows you to modify MIDI events, drop MIDI events and create completely > new MIDI events on your own by script. > > ATM we don't have that event handler (and thus this first level of raw MIDI > processing) yet. Mainly because so far I saw no huge benefit of having it. > But > who knows, maybe I am also missing out a killer use case for that layer. > > CU > Christian > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Christian S. <sch...@li...> - 2017-05-25 22:04:18
|
On Thursday, May 25, 2017 20:34:36 Andrew C wrote: > >After you updated LS to latest SVN it > >should apply the note/velocity changes to the MIDI event as well as to the > >voices, so it should behave as expected by you. > > Well, I updated to the latest svn, but the MIDI data itself doesn't change > with change_note unfortunately, only the voice data. i.e chipmunk effect > occurs if I transpose C3 up to C4 using change_note, rather than triggering > the C4. :S Right, there was a bit more involved, which I hopefully just fixed. At least it behaved correctly now in my latest tests: * change_note() should now reselect the correct region and accordingly the correct sample (no more mickey mouse). and * change_velo() should now also reselect the correct dimension region (if you have a "velocity" dimension in giga, and whatever the term is for sfz and sf2). It is still not changing the actual MIDI event though BTW, which in practice means certain MIDI processing tasks within the sampler like exclusive groups (a.k.a. key groups), key based round robin and the like are all not affected by those two script functions. For those particular use cases adding the mentioned raw MIDI processing script level might make sense. As far as I can see it right now, changing the implementations of change_note() and change_velo() to perform true MIDI event modification is probably not a good idea, since it would require all kinds of MIDI re-processing inside the sampler engine, which would be inefficient. CU Christian |
|
From: Andrew C <cou...@gm...> - 2017-05-27 00:22:13
|
Thanks alot for fixing this, Christian! My script works like a charm now - Already I can see interesting ways to expand it such as subtly varying the tuning of each note played for more humanisation, etc. I'd like to see if I can't code an approximation of a 'poorman's' legato function in NKSP that works by activating the sustain pedal when overlapping notes are detected and turning the instrument into a 'monophonic' voice. I can probably do some cool stuff with, as you said, %KEY_DOWN[] and $EVENT_NOTE. I'm gonna see what I can come up with over the weekend.. Andrew. On Thu, May 25, 2017 at 11:07 PM, Christian Schoenebeck < sch...@li...> wrote: > On Thursday, May 25, 2017 20:34:36 Andrew C wrote: > > >After you updated LS to latest SVN it > > >should apply the note/velocity changes to the MIDI event as well as to > the > > >voices, so it should behave as expected by you. > > > > Well, I updated to the latest svn, but the MIDI data itself doesn't > change > > with change_note unfortunately, only the voice data. i.e chipmunk effect > > occurs if I transpose C3 up to C4 using change_note, rather than > triggering > > the C4. :S > > Right, there was a bit more involved, which I hopefully just fixed. At > least > it behaved correctly now in my latest tests: > > * change_note() should now reselect the correct region and accordingly the > correct sample (no more mickey mouse). > > and > > * change_velo() should now also reselect the correct dimension region (if > you > have a "velocity" dimension in giga, and whatever the term is for sfz and > sf2). > > It is still not changing the actual MIDI event though BTW, which in > practice > means certain MIDI processing tasks within the sampler like exclusive > groups > (a.k.a. key groups), key based round robin and the like are all not > affected > by those two script functions. For those particular use cases adding the > mentioned raw MIDI processing script level might make sense. As far as I > can > see it right now, changing the implementations of change_note() and > change_velo() to perform true MIDI event modification is probably not a > good > idea, since it would require all kinds of MIDI re-processing inside the > sampler engine, which would be inefficient. > > CU > Christian > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
Thanks for helping keep SourceForge clean.
X