# Negative Event IDs



## Big Bob (Jan 29, 2007)

Hi ya all,

Until just recently, I didn't realize there was such a thing as a negative ID number (other than maybe after you let K2 run for a very, very long time :lol: ), but, it turnsò¬¶   P¯¬¶   P°¬¶   P±¬¶   P²¬¶   P³¬¶   P´¬¶   Pµ¬¶   P¶¬¶   P·¬¶   P¸¬¶   P¹¬¶   Pº¬¶   P»¬¶   P¼¬¶   P½¬¶   P¾¬¶   P¿¬¶   PÀ¬¶   PÁ¬¶   PÂ¬¶   PÃ¬¶   PÄ¬¶   PÅ¬¶   PÆ¬¶   PÇ¬¶   PÈ¬¶   PÉ¬¶   PÊ¬¶   PË¬¶   PÌ¬¶   PÍ¬¶   PÎ¬¶   PÏ¬¶   PÐ¬¶   PÑ¬¶   PÒ¬¶   PÓ¬¶   PÔ¬¶   PÕ¬¶   PÖ¬¶   P×¬¶   PØ¬¶   PÙ¬¶   PÚ¬¶   PÛ¬¶   PÜ¬¶   PÝ¬¶   PÞ¬¶   Pß¬¶   Pà¬¶   Pá¬¶   Pâ¬¶   Pã¬¶   Pä¬¶   På¬¶   Pæ¬¶   Pç¬¶   Pè¬¶   Pé¬¶   Pê¬¶   Pë¬¶   Pì¬¶   Pí¬¶   Pî¬¶   Pï¬¶   Pð¬¶   Pñ¬¶   Pò¬¶   Pó¬¶   Pô¬¶   Põ¬¶   Pö¬¶   P÷¬¶   Pø¬¶   Pù¬¶   Pú¬¶   Pû¬¶   Pü¬¶   Pý¬¶   Pþ¬¶   Pÿ¬¶   P ¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P	¬¶   P
¬¶   P¬¶   P¬¶   P ¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P¬¶   P              ò¬¶   P ¬¶   P!¬¶   P"¬¶   P#¬¶   P$¬¶   P%¬¶   P&¬¶   P'¬¶   P(¬¶   P)¬¶   P*¬¶   P+¬¶   P,¬¶   P-¬¶   P.¬¶   P/¬¶   P0¬¶   P1¬¶   P2¬¶   P3¬¶   P4¬¶   P5¬¶   P6¬¶   P7¬¶   P8¬¶   P9¬¶   P:¬¶   P;¬¶   P<¬¶   P=¬¶   P>¬¶   P?¬¶   P@¬¶   PA¬¶   PB¬¶   PC¬¶   PD¬¶   PE¬¶   PF¬¶   PG¬¶   PH¬¶   PI¬¶   PJ¬¶   PK¬¶   PL¬¶   PM¬¶   PN¬¶   PO¬¶   PP¬¶   PQ¬¶   PR¬¶   PS¬¶   PT¬¶   PU¬¶   PV¬¶   PW¬¶   PX¬¶   PY¬¶   PZ¬¶   P[¬¶   P\¬¶   P]¬¶   P^¬¶   P_¬¶   P`¬¶   Pa¬¶   Pb¬¶   Pc¬¶   Pd¬¶   Pe¬¶   Pf¬¶   Pg¬¶   Ph¬¶   Pi¬¶   Pj¬¶   Pk¬¶   Pl¬¶   Pm¬¶   Pn¬¶   Po¬¶   Pp¬¶   Pq¬¶   Pr¬¶   Ps¬¶   Pt¬¶   Pu¬¶   Pv¬¶   Pw¬¶   Px¬¶   Py¬¶   Pz¬¶   P{¬¶   P|¬¶   P}¬¶   P~¬¶   P¬¶   P€¬¶   P¬¶   P‚¬¶   Pƒ¬¶   P„¬¶   P…¬¶   P†¬¶   P‡¬¶   Pˆ¬¶   P‰¬¶   PŠ¬¶   P‹¬¶   PŒ¬¶   P¬¶   PŽ¬¶   P              ò¬¶   P‘¬¶   P’¬¶   P“¬¶   P”¬¶   P•¬¶   P–¬¶   P—¬¶   P˜¬¶   P™¬¶   Pš¬¶   P›¬¶   Pœ¬¶   P¬¶   Pž¬¶   PŸ¬¶   P ¬¶   P¡¬¶   P¢¬¶   P£¬¶   P¤¬¶   P¥¬¶   P¦¬¶   P§¬¶   P¨¬¶   P©¬¶   Pª¬¶   P«¬¶   P¬¬¶   P­¬¶   P®¬¶   P¯¬¶   P°¬¶   P±¬¶   P²¬¶   P³¬¶   P´¬¶   Pµ¬¶   P¶¬¶   P·¬¶   P¸¬¶   P¹¬¶   Pº¬¶   P»¬¶   P¼¬¶   P½¬¶   P¾¬¶   P¿¬¶   PÀ¬¶   PÁ¬¶   PÂ¬¶   PÃ¬¶   PÄ¬¶   PÅ¬¶   PÆ¬¶   PÇ¬¶   PÈ¬¶   PÉ¬¶   PÊ¬¶   PË¬¶   PÌ¬¶   PÍ¬¶   PÎ¬¶   PÏ¬¶   PÐ¬¶   PÑ¬¶   PÒ¬¶   PÓ¬¶   PÔ¬¶   PÕ¬¶   PÖ¬¶   P×¬¶   PØ¬¶   PÙ¬¶   PÚ¬¶   PÛ¬¶   PÜ¬¶   PÝ¬¶   PÞ¬¶   Pß¬·   Pà¬·   Pá¬·   Pâ¬·   Pã¬·   Pä¬·   På¬·   Pæ¬·   Pç¬·   Pè¬·   Pé¬·   Pê¬·   Pë¬·   Pì¬·   Pí¬·   Pî¬·   Pï¬·   Pð¬·   Pñ¬·   Pò¬·   Pó¬·   Pô¬·   Põ¬·   Pö¬·   P÷¬·   Pø¬·   Pù¬·   Pú¬·   Pû¬·   Pü¬·   Pý¬·   Pþ¬·   Pÿ¬·   P               ò¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P	¬·   P
¬·   P¬·   P¬·   P ¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P¬·   P ¬·   P!¬·   P"¬·   P#¬¸   P$¬¸   P%¬¸   P&¬¸   P'¬¸   P(¬¸   P)¬¸   P*¬¸   P+¬¸   P,¬¸   P-¬¸   P.¬¸   P/¬¸   P0¬¸   P1¬¸   P2¬¸   P3¬¸   P4¬¸   P5¬¸   P6¬¸   P7¬¸   P8¬¸   P9¬¸   P:¬¸   P;¬¸   P<¬¸   P=¬¸   P>¬¸   P?¬¸   P@¬¸   PA¬¸   PB¬¸   PC¬¸   PD¬¸   PE¬¸   PF¬¸   PG¬¸   PH¬¸   PI¬¸   PJ¬¸   PK¬¸   PL¬¸   PM¬¹   PN¬¹   PO¬¹   PP¬¹   PQ¬¹   PR¬¹   PS¬¹   PT¬¹   PU¬¹   PV¬¹   PW¬¹   PX¬¹   PY¬¹   PZ¬¹   P[¬¹   P\¬¹   P]¬¹   P^¬¹   P_¬¹   P`¬¹   Pa¬¹   Pb¬¹   Pc¬¹   Pd¬¹   Pe¬¹   Pf¬¹   Pg¬¹   Ph¬¹   Pi¬¹   Pj¬¹   Pk¬¹   Pl¬¹   Pm¬¹   Pn¬¹   Po¬¹   Pp¬¹   Pq              s of code will do the same thing.

```
change_vol(by_marks(MARK_2+MARK_5), atn, 0)

{ or }

  change_vol((MARK_2+MARK_5) .or. -2147483648, atn, 0)
```

Of course since we are dealing with bits, the hexadecimal representation of these values would be more meaningful but unfortunately the KSP doesn't allow us to enter or display numbers in any base other than decimal. The value -2147483648 is merely the biggest negative number (in two's complement) which is 80000000h in hexadecimal (or in binary, a one followed by 31 zeros). Thus the argument MARK_2+MARK_5 = 4h + 20h = 24h = 36 in decimal.

Now, when you call a function with an id having the sign bit set, the KSP removes the sign bit (effectively) and then it logically ANDs the remaining value with each active event's bitmap. If the result is non-zero, the event is considered part of the specified 'set'.

Since there are only 28 mark constants, and the sign bit serves as a flag, there are 3 bits unaccounted for: Thus, the use of Bit 0, and bits 29 and 30 are not disclosed by NI. However, I have noted that the system variable named ALL_EVENTS = -1 or FFFFFFFFh in hexadecimal. And, in the light of this, maybe our practice of using -1 to mean 'no event' should be reviewed. I think it's still OK because no automatically assigned event is ever negative but maybe using 0 would be safer?

Knowing how the KSP Mark system works, allows us to use it more conveniently. For example, suppose you have a group of event id numbers in an array named *Notes[5] *and you have an index variable *nx*, assumedly constrained to the range of 1 to 28, and you want to 'tag' this set of events as belonging to group *nx*, here's one way to do it.


```
for i := 0 to 4
  set_event_mark(Notes[i],sh_left(1,nx+1))
end for
```

Altenatively, instead of writing the sh_left expression, you could define an array named Mark as follows:


```
declare Mark[29] := (0, MARK_1, MARK_2, MARK_3, ...  MARK_28)

{ and then use }

for i := 0 to 4
  set_event_mark(Notes[i],Mark[nx])
end for
```

You could now decrease the volume of all 5 notes in group *nx* by 3db with the following:


```
change_vol(by_marks(Mark[nx]),-3000,1)
```

One thing we may have to watch out for is that scripts later in the chain could turn on additional mark bits (although I don't think there is a way to turn off bits). And, talking about letting K2 run for eons, I hope NI doesn't simply 2's complement increment the last event id to get the next one. Hopefully when they reach 7FFFFFFFh they wrap around to zero and not advance to 80000000h :roll: . Anyway, I found this all rather interesting so I thought I would share it.

God Bless,

Bob


----------



## Nickie Fønshauge (Jan 29, 2007)

Brilliant deduction, Bob. Thanks for letting us know. I have not used event marks yet, but if/when I get to that stage, I will certainly keep this in mind.

BTW, are you sure "when all 32 bits are set to one" isn't -0? KSP does know the number -0. Shouldn't -1 be "all 1 except bit 0"?


----------



## Thonex (Jan 29, 2007)

Thanks for this Bob... I'd wager about 50% of this post went over my head.... but hopefully one day I'll be able to enjoy your discoveries. 

Like Nicky, I haven't used the Mark command yet... it seems cool, but I don't really understand how to use it. Is it only for marking bits?... Or can I mark notes or other things?

Sorry to be off topic here.

Cheers,

T


----------



## kotori (Jan 30, 2007)

Hi Bob,
Thanks for posting this. To me it's seems that using -1 to signify no ID should be safe as long as one doesn't use it in any call to the change_... functions.

Cheers,
Nils

PS. I got your mail. I'm just very busy at the moment, but I'll try to respond as soon as possible. DS.


----------



## Big Bob (Jan 30, 2007)

Nickie Fønshauge @ Mon Jan 29 said:


> Brilliant deduction, Bob. Thanks for letting us know. I have not used event marks yet, but if/when I get to that stage, I will certainly keep this in mind.
> 
> BTW, are you sure "when all 32 bits are set to one" isn't -0? KSP does know the number -0. Shouldn't -1 be "all 1 except bit 0"?



Hi Nickie,

I understand your logic but, in two's complement format (unlike sign/magnitude format), there is no -0. As a result, the biggest negative number is one larger in magnitude than the biggest positive number. The value of 1111..1110 is -2.
1000,0000,0000,......0000 is the biggest negative number, ie -2,147,483,648 and
0111,1111,1111,....1111 is the biggest positive number, ie 2,147,483,647. In sign/magnitude format (which is probably more logical for humans but not as friendly for computers :wink: ) -1 would be 1000,0000,0000,.....0001 and
1000,0000,0000,...0000 would then be -0. Clear as mud?



> Like Nicky, I haven't used the Mark command yet... it seems cool, but I don't really understand how to use it. Is it only for marking bits?... Or can I mark notes or other things?


Hi Andrew,

I'm sorry if I confused the issue for you a little. Actually, using marks has nothing to do with 'bits' other than internally for the KSP. As far as scripters are concerned, marks are used to 'tag' events so they can be referenced as a group. Whenever you use a function like note_off(id), id can be the ID of one specific event or it can refer to a group of events. For example, if you write:

```
note_off(by_marks(MARK_1+MARK_2))
```
all note events 'tagged' with mark 1 or mark 2 will be turned off. You 'tag' events using the set_event_mark() function. Clear as London fog?



> Thanks for posting this. To me it's seems that using -1 to signify no ID should be safe as long as one doesn't use it in any call to the change_... functions.


Hi Nils,

I agree. However, I'm thinking that sometimes when we assign NoID to some event like NewNoteID, the intention might be to render a call to say note_off(NewNoteID) impotent. If so, we wouldn't want to use -1 since such a call would be anything but impotent. Since the idea of NoID sort of means 'there is no currently active ID that will match this', 0 might be a better choice (I'm reasonably sure that IDs are assigned starting at 1 and go up from there). However, as you say, if one is careful to not allow a call to any function with an id variable that might be set to NoID, then there won't be a problem. However, I think in the distant past that I have used NoID to render certain calls impotent and I guess that's what raised the red flag for me.

BTW There's no hurry with responding to my last email, we'll get this project done when we get it done. While I'm not as busy as you, I need all the time I can get to keep up with you :lol: .

PS I found a small problem with V1.20 of the NL Editor which I'll post in the V1.20 thread.

You all have a beautiful day,

God Bless,

Bob


----------



## Nickie Fønshauge (Jan 30, 2007)

Big Bob @ 30th January 2007 said:


> I understand your logic but, in two's complement format (unlike sign/magnitude format), there is no -0. As a result, the biggest negative number is one larger in magnitude than the biggest positive number. The value of 1111..1110 is -2.
> 1000,0000,0000,......0000 is the biggest negative number, ie -2,147,483,648 and
> 0111,1111,1111,....1111 is the biggest positive number, ie 2,147,483,647. In sign/magnitude format (which is probably more logical for humans but not as friendly for computers :wink: ) -1 would be 1000,0000,0000,.....0001 and
> 1000,0000,0000,...0000 would then be -0. Clear as mud?


I understand what you are saying, Bob, and I now know the difference between two's complement and one's complement :idea: I was just thinking: does Kontakt use both one's and two's complement? Because I have seen Kontakt use -0 in other situations, so it obviously does use one's complement sometimes.


----------



## kotori (Jan 30, 2007)

Nickie Fønshauge @ Tue Jan 30 said:


> Because I have seen Kontakt use -0 in other situations, so it obviously does use one's complement sometimes.



Maybe this -0 is really a rounded floating point number between 0.0 and -1.0 - just a thought.


----------



## Big Bob (Jan 30, 2007)

> I understand what you are saying, Bob, and I now know the difference between two's complement and one's complement I was just thinking: does Kontakt use both one's and two's complement? Because I have seen Kontakt use -0 in other situations, so it obviously does use one's complement sometimes.



Could you give me an example Nickie? If it's just some internal value that K2 uses, maybe Nils is right. For example when displaying values in an edit box, the KSP apparently does some internal arithmetic and floating-point formatting to display fractional values. But, as far as I know, all integers in the KSP (that we can get our hands on) are interpreted by the KSP as being in 2's complement form.

However, just to clarify something, if a 32-bit value consists of all ones, you can call it or display it any way you wish. For example, we could agree to interpret all values as positive. In which case an integer with 32 ones would have a value of
4,294,967,295. It's only a matter of how the KSP has decided to display integers and how it uses them in arithmetic operations. For bit-wise operations it doesn't matter whether you consider bit 32 a sign bit or not.

Since 32-bit integers can contain such large values, it's a little difficult to see what's going on but suppose for the moment that we were dealing with only 4-bit values. If we increment 0111 we will get 1000. Now you can either say we incremented 7 and got 8 or you can say we incremented 7 but it overflowed and 'wrapped around' to -8 (since 1000 is -8 in 2's complement format). Similarly, if we have 0000 and we subtract one from it, we'll get 1111 (with a discarded borrow). You could view this as decrementing zero and getting 15 or as decrementing zero and getting -1 (using 2's complement). To sort of demonstrate that the KSP interprets integers in 2's complement, try setting a variable to 2,147,483,647 (the max positive value) and then increment it and redisplay it. The KSP will say that it's -2,147,483,648. But the bit pattern is actually changing from 0111,1111,...1111 to 1000,0000,....0000.

I'm sorry if I opened a can of worms here but I just happen to be a bit twiddler from way back. :lol: 

God Bless,

Bob


----------



## Nickie Fønshauge (Jan 30, 2007)

Bob, -0 occurs in a knob declared as 

``````````*declare* ui_knob value (-64, 63, 1)

whenever I set it to 0 with the mouse. For some obscure reason, however, playing a note (any note, even one, that isn't mapped) or touching almost any other script GUI element reverts it to "0". With one exception: a knob that is declared exactly the same way as those, that do revert the value to "0" :

``````````*declare* ui_knob value (1,127,1)
Go figure!

Andrew, too many fruitless years at the university studying Computer Science and Mathematics are hard to forget completely, even though I tried pretty hard for some years.


----------



## Thonex (Jan 30, 2007)

Nickie Fønshauge @ Tue Jan 30 said:


> Andrew, too many fruitless years at the university studying Computer Science and Mathematics are hard to forget completely, even though I tried pretty hard for some years.



Heh... Well... I was accepted to universities for computer science and math.... but much to my mother's disappointment (at the time) I decided to major only in music. :lol: 

I think it was the right choice though... when I look at you guys... you are clearly on another level.

Cheers,

T


----------



## Big Bob (Jan 30, 2007)

> Bob, -0 occurs in a knob declared as
> 
> ``````````declare ui_knob value (-64, 63, 1)
> 
> ...



How wierd! But, it does look like numbers displayed with controls may be in a different class because of the 3rd scaling parameter. Perhaps, as Nils suggested, the internal value is in floating point and when the value is slightly less than zero (for example -0.00006) but only 3 decimal digits are being displayed, a -0 shows up?

BTW If any of you would like to see what the bits look like for any KSP integer, I'm attaching a pair of math functions that I wrote few days ago. These functions may eventually be part of an extended math library but I don't have any documentation for them yet. However, I think with the simple test script as a guide you won't have any trouble figuring out how to use these routines.

God Bless,

Bob


----------



## pocoapoco (Jan 30, 2007)

psst...
hey bob, ummm...
mark_5=10h
All fun aside thanks for the post. It is good info to have.


----------



## Big Bob (Jan 31, 2007)

pocoapoco @ Tue Jan 30 said:


> psst...
> hey bob, ummm...
> mark_5=10h
> All fun aside thanks for the post. It is good info to have.



au contrair!

MARK_5 = 20H = 32

Try this:

on init
message($MARK_5)
end on

Remember that MARK_1 is not the *lowest* bit (bit zero) it is actually bit 1 which has a value of 2H = 2. 

However, I did mistakenly say that MARK_2 was 2h when it is actually 4h :oops: So thanks to your post about MARK_5, I'll go back and edit the 22h statement because it should have been 24h.

God Bless,

Bob


----------



## pocoapoco (Jan 31, 2007)

Ah, ok. I've never used the marks in the scipting language yet, so I had just assumed that they were in bit order starting at the lowest bit. I guess I can also incorporate the use of the "embarrased emoticon" :oops: . 
By the way, do you know of any legato patching technique that is meant to be specificly applied to bowed string instruments like violin? I'm still involved in doing this Shostakovich 10th symphony and am still trying to improve things. Some of the equalpower curves applied to attacks and releases might do an ok job, but in a violin thre's a short amount of time when the players finger rests on the string, but the string has not yet come into contact with the fingerboard. I'm not exactly sure how this will effect the sound in transition. It's true it may not even be relevant when talking about an entire section as opposed to a solo instrument, as 14violins, no matter how well skilled, will almost never be perfectly in sync with each other. But if you have any input, it would be greatly appreciated.


----------



## Big Bob (Feb 1, 2007)

Hi Mr Little by Little :wink: 



> By the way, do you know of any legato patching technique that is meant to be specificly applied to bowed string instruments like violin? I'm still involved in doing this Shostakovich 10th symphony and am still trying to improve things. Some of the equalpower curves applied to attacks and releases might do an ok job, but in a violin thre's a short amount of time when the players finger rests on the string, but the string has not yet come into contact with the fingerboard. I'm not exactly sure how this will effect the sound in transition.



I'm afraid that sort of thing is out of my domain (I'm mostly Dixieland Jazz and such) but maybe someone else could give you some pointers. Andrew (aka Thonex) managed to coax some pretty convincing Violin stuff from SIPS so you might ask him. 

BTW SIPS is not really a 'load and go' tool, you have to learn how to use it musically and that takes some time investment. On the other hand SIPS, like anthing else, does have its limitations. The only reason I mention this is that I have seen a few posts from people who 'tried' using SIPS and were disappointed when it didn't just solve all their problems automatically. Yet I have heard some pretty convincing stuff done with SIPS by those who took the time to learn how to use it properly and then develop the real time MIDI CC techniques needed tò®   Pl®   Pl ®   Pl!®   Pl"®   Pl#®   Pl$®   Pl%®   Pl&®


----------



## steff3 (Jan 30, 2009)

Hello,

just thought I warm this up again ....

I am also currently using marks and in 3.02 it seems that marks are positive and that they are the integer of 2^<mark-number> - e.g. Mark 16 is 2 ^16 ~65xxx 

the thing that concerns me here is - did they change that over the versions? because of course it is more convenient to assign marks by math than by MARK_1 to MARK_28 ... (if they change that one has to use the long way though ...)

best,
thanks


----------



## Big Bob (Jan 30, 2009)

> the thing that concerns me here is - did they change that over the versions?



Hi steff,

I'll check this out later today but I don't think it has changed between K2 and K3. You may also have misunderstood my original post. The constants such as MARK_1, *are* positive. It is only when you use the function *by_marks *(which is required if you want to use any collection of marks in place of an ID) that a negative ID is created.

After I check this out, if there is some difference in how K3 has implemented marks, I'll edit this post later today.

Maranatha,

Bob


----------



## steff3 (Jan 30, 2009)

Well,

yes, then I misunderstood you original post ... I was only looking at the marks themselfs .... hmmm, it might be secure to implement them mathematically then ...

but then ...

>>
After first launching K2, the first note event ID used is 1 and subsequent IDs are assigned sequentially as 2, 3, 4, ... etc. 
>>
here - I mean when I so

note on
message(""&$EVENT_ID&"")
end on

the numbers are more 0,2,5,8 etc. maybe I miss something there as well ...

thanks

best


----------



## Big Bob (Jan 30, 2009)

> After first launching K2, the first note event ID used is 1 and subsequent IDs are assigned sequentially as 2, 3, 4, ... etc.



This is correct, ie assigned ids are ever increasing positive integers during any given session with Kontakt. I don't know if NI has a clamp at 0x7FFFFFFF or not (since I've never run a Kontakt session long enough to allow K2/3 to create over 2 billion events) but I would hope so. If the current event number ever reaches 0x7FFFFFFF the next one would be 0x80000000 which would then be treated as negative. Probably the best thing to do would be to reset to 1 after 0x7FFFFFFF but it may be that NI figures no one will get to this condition.

Since normal ids are always positive then, NI can distinguish a by_marks id from a normal id by simply examining the sign bit. Try re-reading my opening post for this thread a little more carefully, I think the information is all there.

BTW I ran a quick check of K3 vs K2 and I see no changes in this area.

Maranatha,

Bob


----------

