What's new

Scripted release triggers

OnKey

New Member
I have scripted release triggers, and I am trying to control there volume, but for an unknown reason

on release
play_note($EVENT_NOTE,$EVENT_VELOCITY,0,-1) {playing the release triggers}
change_vol($EVENT_ID,$Release_Volume,1) {changing there volume}
end on

Is not changing the volume of the release triggers but instead the tail of the ON notes.

What should I change to make it control the volume of the release triggers? A real head scratcher, I presumed this would work.
 
You don't want to use EVENT_ID but rather the id of the new note you are creating in the RCB

Code:
on release 
id := play_note($EVENT_NOTE,$EVENT_VELOCITY,0,-1) {playing the release triggers} 
change_vol(id,$Release_Volume,1) {changing there volume} 
end on

Rejoice,

Bob
 
Thank you so much BOB works great on releases, what would you suggest for ATTACK notes ?

I have

on note
ignore_event($EVENT_ID)

$Attack_id := play_note($EVENT_NOTE,$EVENT_VELOCITY,$Offset,-1)

fade_in($Attack_id,$Attack)

end on

This works perfectly when playing 1 note at a time, but when playing a chord, it ignores the attack value and just plays as if no fade in has been set. : (

any thoughts on this?
 
Are you sure? Just looking quickly at the code it seems like it should work polyphonically as well as monophonically. Are you sure there isn't some problem with the value of Attack changing :roll:

When I get a chance I'll try to set this up and see what it does for me (if you haven't nailed it by then). But it may be a while before I can get to it.

Rejoice,

Bob
 
facepalm, I had placed something before the ignore note causing a small big of lag.

Thats all sorted, although now the ignore_event on the on note, seems to be making the change_vol on the on release no longer function. : ( is there a sneaky way round this?



thanks again BOB, scripting legend is not even close enough :)
 
Can you post simplified (but accurate) versions of both your NCB and RCB at the same time?
 
Sure, atm I have different slots doing different things, the most accurate way to describe it would be.

The reasoning behind using different slots was so ignoring the even ID on NCB wouldn't screw up the work on the ON NOTE in SLOT 01. And for the attacks it works like a charm, but now sadly it is ignoring change of volume on the releases.

SLOT 01
on note
{disallowing / allowing various groups}
end on

on release
{disallowing / allowing various groups}
$Release_id := play_note($EVENT_NOTE,$EVENT_VELOCITY,0,-1)
change_vol($Release_id,$Release_Volume,1)
end on


SLOT 02
on note
ignore_event($EVENT_ID)
$Attack_id := play_note($EVENT_NOTE,$EVENT_VELOCITY,$Offset,-1)
fade_in($Attack_id,$Attack)
end on

on release
end on
 
I'm about ready to quit for the day but I'll check in again tomorrow morning if you haven't solved it by then.
 
The reasoning behind using different slots was so ignoring the even ID on NCB wouldn't screw up the work on the ON NOTE in SLOT 01.

No need to use two slots for this. Get acquainted with set_event_par_arr(), which uses $EVENT_PAR_ALLOW_GROUP to allow/disallow groups on event level. This is what you need, and what you're doing here will then be possible to be done in one slot only.
 
And for the attacks it works like a charm, but now sadly it is ignoring change of volume on the releases.

I think that the release note you are generating in the RCB of slot 1 will be killed in the NCB of slot 2 because of the unconditional ignore event there.

One way to solve this problem would be to 'tag' your note events so you can intelligently deal with different events in different ways farther down the line.

However, why don't you first follow MK's suggestion and recast everything into a one-slot implementation. It will probably be easier then to deal with the rest of your problems.

Rejoice,

Bob
 
Top Bottom