Fingered Tremolos (Shakes)

[Francois2010]

Hello.
I consulted the guide Notion3 about Fingered Tremolos (Shakes). I used the same notes as in the example Notion3 Guide (see file join measure 1).
It seems to work only if the notes are conjoined as in measure 2 of my file.

Do I missed something?

Thank you!

[Surfwhammy]

Hello.
I consulted the guide Notion3 about Fingered Tremolos (Shakes). I used the same notes as in the example Notion3 Guide (see file join measure 1).
It seems to work only if the notes are conjoined as in measure 2 of my file.

Do I missed something?

Thank you!

I did a quick test where I used the Piano from Miroslav Philharmonik, and both measures play correctly . . .

However, if the interval of the two notes is greater than a whole step, then Miroslav Philharmonik does not do the shakes . . .

Hence, it appears that the rules are (a) that shakes with the Notion 3 London Symphony Orchestra (LSO) Piano require notes that are separated by a semitone (or half-step) and (b) that shakes done with the Miroslav Philharmonik Piano require notes that are separated either by a semitone or a tone (halfstep or whole-step, respectively) . . .

Overall, I think that it probably is better to specify each note, which in this instance will be 64th notes, since it is more precise and does not depend on the VSTi library and the computer algorithm for fingered tremolo (a.k.a., "shakes") . . .

Using high-level abstractions can save a bit of time, but it moves the determination of what happens with the music from (a) the composer to (b) the specific VSTi library and computer algorithm . . .

Additionally, since it is high-level activity, it will tend to be more likely to change from version to version, which is the way high-level activities usually behave in computer programs, where high-level activities typically are done by grouping low-level activities in various ways, and the problem is that while low-level activities are more enduring or persistent, the ways they are combined to create high-level activities is quite subject to change, especially when software engineers are a bit bored and have nothing better to do than to improve things that really do not need improving, since for the most part software engineers and their managers nearly ever actually comprehend the beauty of the following adage in its entirety . . .

If it is not broken, then do not fix it!

Explained another way, at some point you will have a catalog of songs done in Notion 3 according to the various rules that Notion 3 follows, so from the perspective of the long run I think it makes sense to avoid using techniques, parameters, options, and so forth and so on that are likely to evolve over time . . .

For example, i suggest that an eighth note is quite unlikely to change from one version of Notion to another version since an eighth note it is a low-level entity, but I also suggest that the way trills, shakes, and similar high-level articulations behave from one version to the next is an entirely different matter . . .

Hence, focusing on primitives probably is a better long term strategy, even when it requires more inputting work initially . . .

Stated another way, my experience over the years strongly suggests that for a variety of reasons computer programs change some of their behaviors from one version to the next, and I think that the smart way to reduce the impact of such changes is to focus on doing everything in the most simple ways possible, which nearly always maps to using primitives or low-level actions and entities, even when it requires more initial work, which is fabulous . . .

Fabulous!

P. S. In the not so distant future, the computer hardware and software industry will change everything by focusing all new hardware and software exclusively in the 64-bit universe, at which time everyone will have no option but to purchase both (a) new hardware and (b) new software . . .

Currently, it is more of a "kind of but not exactly" and "optional" thing, since even though there are 64-bit computer processors and operating systems, there are few applications that are both (a) 64-bit and (b) specifically are designed and programmed for multitprogramming, multitasking, and multiprocessing hardware and operating systems, with additional emphasis on multicore processors . . .

A well-written C or C++ program can be compiled for 64-bit use with a few simple compiler options, but this does not make it capable of doing much more than it already was doing when it was compiled for 32-bit use, and in some instances the program will be slower rather than faster . . .

Speed comes from having (a) multiple processors and (b) multiple cores, as well as having more memory and the ability actually to use it, but the bulk of the speed comes from dividing a long series of sequential steps into several separate tasks that for the most part can be run independently on essentially dedicated hardware--at least for a while--and this requires a lot of design work, as well as considerably more skill in juggling tasks with respect to determining when activities can be asynchronous; when activities must be synchronous; when asynchronous and synchronous activities must coalesce or become synchronized; and so forth and so on than sequential programming does . . .

This is on the horizon, but when it will appear is another matter, and the only certain thing is that it will be very expensive, since it will require both a new computer and new software, so one strategy is to start saving something in the range of $2,500 to $5,000 each year, and perhaps in five years you will have saved enough money to get everything, if all of it has appeared in five years, which is possible, although probably not for the advanced multiprocessing, multiprogramming, multitasking, multicore stuff, since another fact of the matter is that doing the advanced stuff requires having at least a few software design engineers who, for example, have the mental abilities and skills required to compose an elaborate symphony for an entire orchestra, which is not such a commonly available set of abilities and skills on this planet with respect to advanced mentation, software design, and computer programming, really . . .

Really!