Scope of #define

Discussion on the SFZ implementation and opcodes available in the ARIA engine.

Moderators: eric_telemaque, davidv

michaelwayneharwood
Posts: 14
Joined: Fri Nov 27, 2015 12:04 pm

Scope of #define

Postby michaelwayneharwood » Thu Dec 03, 2015 11:56 am

Based on my experiments with the #define directive it has no scope in regards to section overrides, and the parser will overwrite any previous values when it encounters a new #define directive with the same variable name. In the following example the following behavior exhibits itself:

Code: Select all

<global>
#define $test *saw  // $test equals *saw at this point

<group>
#define $test *sine // $test now equals *sine
<region> sample=$test key=e1

<group>
<region> sample=$test key=f1 // $test still equals *sine

<group>
#define $test *saw
<region> sample=$test key=g1 // $test now equals *saw at this point


I just want to make sure that this behavior is expected, and that if I code an SFZ using this assumption I will not have trouble in future iterations of the player.

Thanks guys!

davidv
Site Admin
Posts: 1567
Joined: Tue Mar 02, 2004 7:23 pm
Contact:

Re: Scope of #define

Postby davidv » Thu Dec 03, 2015 12:57 pm

It's been a while since I've looked at this code, but this seems like correct CPP behaviour, with the exception that a normal C Pre Processor would warn/error nag you are repeated #define's not previously #undef'ed,.
David Viens,
Plogue Art et Technologie Inc. Montreal.
http://www.plogue.com

michaelwayneharwood
Posts: 14
Joined: Fri Nov 27, 2015 12:04 pm

Re: Scope of #define

Postby michaelwayneharwood » Thu Dec 03, 2015 1:08 pm

Thanks David!

michaelwayneharwood
Posts: 14
Joined: Fri Nov 27, 2015 12:04 pm

Re: Scope of #define

Postby michaelwayneharwood » Fri Dec 04, 2015 12:24 pm

Here's an example of using #defines to speed up coding. This is for a sample library I am building for a harp. Each note of the harp is sampled chromatically, and the round-robin scheme uses samples from the notes above and below the triggered region, in addition to the main sample. By using #defines I am able to quickly build a group for each note, and easily modify a variety of parameters without searching through tons of code. It allows for quick coding, and easier troubleshooting.

The only downside is potential issues with code readability, but reasonable inline documentation practices should alleviate any serious issues. I am a big fan of self documenting code.

Code: Select all

///////////////////
// Sustain Notes //
///////////////////

//
// f1
//
<group>
#define $rr1 e1
#define $rr2 f1
#define $rr3 f#1

// Assign f1 as triggering note for region
lokey=$rr2 hikey=$rr2

seq_length=3

//Use sus-e1.wav for the sample, with a sample keycenter of e1
<region> sample=sus-$rr1.wav pitch_keycenter=$rr1 seq_position=1 

//Use sus-f1.wav for the sample, with a sample keycenter of f1
<region> sample=sus-$rr2.wav pitch_keycenter=$rr2 seq_position=2

//Use sus-f#1.wav for the sample, with a sample keycenter of f#1
<region> sample=sus-$rr3.wav pitch_keycenter=$rr3 seq_position=3

//
// f#1
//
<group>
#define $rr1 f1
#define $rr2 f#1
#define $rr3 g1

// Assign f#1 as triggering note for region
lokey=$rr2 hikey=$rr2

seq_length=3

//Use sus-f1.wav for the sample, with a sample keycenter of f1
<region> sample=sus-$rr1.wav pitch_keycenter=$rr1 seq_position=1

//Use sus-f#1.wav for the sample, with a sample keycenter of f#1
<region> sample=sus-$rr2.wav pitch_keycenter=$rr2 seq_position=2

//Use sus-g1.wav for the sample, with a sample keycenter of g1
<region> sample=sus-$rr3.wav pitch_keycenter=$rr3 seq_position=3


Return to “SFZ Programming”

Who is online

Users browsing this forum: No registered users and 2 guests