< Back to IRCAM Forum

Event Attributes

Antescofo
#1

Yesterday I found out that a @staccato attribute on a single note event can cause Antescofo to drop out for quite a while (about 20 more events, rests not counted). Indeed, the first missed note is already short by duration (a double-croche, i.e. 1/4 beats) and even in a moderately slow tempo (e.g. BPM 69) the actual duration won’t be less than the notated value, at least if played by a woodwind instrument. But it is common in musical scores to write things like this, as staccato is not only a durational indicator but an articulation which also influences the attack etc. Well, I learned that one should be very careful with attributes like @staccato in an Antescofo score. For the time being I removed all occurrences of @staccato in my score.

When should one use event attributes concerning playing techniques in Antescofo? According to the reference there are currently two such attributes (@staccato and @pizz). Does the actual duration of notes influence the correlation to events in the score? Does it make sense to use @pizz also for lip and tongue slaps on a woodwind? (Actually instrumentalists prefer the term “pizzicato” over “slap” because the latter term might describe the technique more correctly but has been used for too large a variety of similar techniques.)

Another question regarding the @hook attribute: Will it help Antescofo to realign with the performance after a missed event (be it that it has been left out in the performance or that the follower failed to detect it)? Will a @hook on an easily detectable event help to get along others which are less easily detected, like repeated pitches, sounds with little harmonic saturation (like short percussive sounds), possibly rather soft (like aeolian on a flute), or smallish pitch fluctuations?

Thank you very much for some advice…

#2

@KYL: What you describe on @staccato attribute can be a potential bug! Can you send us an score excerpt for this? If I understood correctly: Once entering the staccato event, Antescofo holds there and misses 20 or more events? Did it catch up later?

The @hook attribute is actually obsolete and if I remember correctly does not have any effect currently! We were using that attribute in early versions of Antescofo to force Antescofo to detect that event and never miss it! And it was never working as advertised since doing such logical progression is not as easy as one would think in a probabilistic system such as Antescofo! :slight_smile: However you should be able to get around your extended techniques (especially on Flute or Winds) using a regular score.

Also, let us know which version of Antescofo you are using.

#3

@Arshia: Alright, so it’s not a misconception of the @staccato attribute on my side?

Attached an excerpt from the Antescofo score (“Structure verticale” for flute, electronically processed in real-time with the help of Antescofo). I marked the two points of interest with a comment beginning with “@Arshia”. Let me know if you need more material which I could send to your e-mail account.

The version I’m using is Antescofo v0.92. The host application is Max 7.31, the operating system is Mac OS X Yosemite (10.10.5).

All the best, Kai Yves

ps. What I forgot to mention: Reexamining the measure with the “staccato” note I realized it could also be the grace note attached to the latter which Antescofo misses. But Antescofo perfectly follows the passage when dispensing with the @staccato attribute.

verticale-20161019-excerpt.asco (11.7 KB)

#4

If I understand correctly (looking at your attached score and description) Antescofo somehow gets lost around m30, but continues and catches up correctly on m37.

First thing to try: You use micro-tonal pitches. I suggest that you add VARIANCE 0.2 at the beginning of your score to make Antescofo sensibility to pitches tighter. Default is 0.3. Try this first.

Second: As you mentioned, there’s a grace note before the @staccato on measure 30. Would it work if you give a duration to the grace note? Let’s say instead of zero your transform NOTE 7350 0 to NOTE 7350 1/8 (or even 1/10)?

#5

Alright, I’ll try the two things later today and will update you.

#6

@Arshia: Both of your proposed changes work – but confusingly, also my original version now works, at least concerning the note with the @staccato attribute. I’m observing such an unsteady behaviour of the system (Max with Antescofo and the configuration consisting of patch and score) from time to time, it seems to depend on the starting point in the score (using the fast-forward feature of Antescofo), how often a section has been performed etc. Several times I was looking for an error in my score (or trying to properly initialize the state for a rehearsal mark) and finally restarted Max to then see all things work like expected. Back to the @staccato attribute: Might it be that removing it invalidated some kind of a cache or a similar optimisation mechanism?

The next event in the score, the long aeolian pianissimo indifferente note, is of course much more difficult to detect. During my tests yesterday, when I started the score from the label “3c a. D”, the aeolian note and the subsequent ordinario were well detected and transposers and ring modulators were faded up in m.34 as written in the score; when starting from the beginning of the piece, the electronic “instruments” were not faded in again before the pitch change (Bb4 after several repetitions of A4) in m.35. (Maybe there are too few pitch changes in my music…) It wouldn’t astonish me if repeating the test today won’t reproduce that difference. Well, the whole stuff is quite complex. But I’d like to understand how I can tweak the configuration and the score to get a more reliable and stable result.

#7

Hello Kyl.

There is no cache implied by the @staccato attribute. The behavior of the listening machine at some point in time, depends on the past recognitions. So, it is not exactly the same to recognize some event just after a fast-forward and to recognize this event after the recognition of the previous event.

For the fading: remembers that actions are triggered only when the corresponding event is detected or detected as missed. The listening machine may be stuck to the recognition of an event e, but then recognize a latter event e’. Then, all event between e and e’ are recognized (at the same time) as missed (and their actions are triggered if they are not labeled @local).

#8

Hello JLG,

does “start”, “fast-forward”, or “stop” reset the listening machine, i.e. let it forget all events it has processed before? Sometimes, when going back and forth in the piece while trying out different things, and working with a pre-recorded performance, it seems that the behaviour of Antescofo at a given point is different without having changed something at that point or before it. This is why I suspected some caching scheme or similar. Especially regarding repeated attacks of the same pitch and very soft attacks (aeolian pianissimo) I’m often at a loss because I don’t know whether better to go by time or by attack. Sometimes Antescofo does well recognizing a repeated attack but then again not. Is it possible to obtain a better control on that with event attributes or maybe setting configuration parameters, e.g. regarding the threshold for silence?

#9

Hello Kyl.

does “start”, “fast-forward”, or “stop” reset the listening machine, i.e. let it forget all events it has processed before?

Yes.
(To be precise, there is a version of start that takes as argument the name of a preloaded score and in this case, there is no reset of the listening machine because the command is intended to continue the execution with the preloaded score. But the command you mention reset the listening machine)

This is why I suspected some caching scheme or similar.

No meaning that there is no caching involved, but yes because recognizing a C4 after a silence is not the same as recognizing a C4 after a D3. The event previously recognized impacts the recognition of the next event. Especially in the case of repeated events.

Especially regarding repeated attacks of the same pitch and very soft attacks (aeolian pianissimo)

If you have repeated events with very soft attack, the listening machine must decide between the recognition of the first event or the recognition of the second event considering that the first event has been missed. You got the general idea: the musical configuration you describe cumulates the difficulties.

I’m often at a loss because I don’t know whether better to go by time or by attack

If you are asking if it is better to trigger actions through delays or to anchor them on the corresponding event, well the answer depends on the musical configuration. If some events are difficult to recognize, it is better to trigger the action through a previous ‘easy to detect’ event and a delay. Using a dynamic target synchronization strategy (https://goo.gl/4OFiyV) combines some advantage of being @tight (anchoring the action to the corresponding musical event) and the advantage of @loose (trusting the tempo and depending only on the detection of the triggering event).

Is it possible to obtain a better control

An important point is the calibration (and the recording mic). If the dynamic is varying a lot you can try to change the calibration level (https://goo.gl/LHnt1w). Some enhancement towards automatic calibration are planed for the next version of antescofo.

Notice also that adjusting the parameter of the listening machine are not the only approach to tackle the problem. As mentioned above, changing the way actions are triggered is a possible path to overcome the limitation of the listening machine.

#10

@Kyl: re-reading all your messages here’s an important second thought: I believe you might have a calibration problem. Copy the Calibration patches from Antescofo help into your patch and observe the calibration parameter on problematic passages. If when your instrument is not playing this value goes higher than 0.5 then there’s a problem and you need to lower your input. This helps Antescofo discriminate between your input and everything else (including silence and/or background sound). And it becomes crucial on repeated events. You usually set this once for a performance.

BTW: We are working on a totally new calibration method which is turning out to be much more robust than the current. We’ll keep everyone posted.