I have been using the line_notifier to detect any changes in the pattern. But, is there any quicker way or function to detect only the pattern change only for the notes?It seems that line_notifier seems somewhat “aggressive”.
That is, insert, change or delete a note, including the note-off, that returns a notification. It does not need to work with the other parameters, nor with the effect parameters, only with the values of notes (range of note_value: 0 - 121).
Example:
Step one: select and copy several lines of a track with notes. Here the function should not trigger a notification.
Step two: paste. Here the function should trigger a notification.
or
Insert a note (C-0 to B-9)
Insert a note-off
clear a note…
This notifier should be instantaneous. It should not take longer if several notes are inserted at the same time, for example. Can this be done?
[…] is there any quicker way or function to detect only the pattern change only for the notes?
The line notifier is the only thing available for detecting changes made to pattern data.
You’re not telling if you need the notifier to bang only once when the user pastes a patterntrack/block. In that case, you will have to make your own filter that never will be perfect.
The line notifier is the only thing available for detecting changes made to pattern data.
You’re not telling if you need the notifier to bang only once when the user pastes a patterntrack/block. In that case, you will have to make your own filter that never will be perfect.
Ok, it seems that there is no other remedy than using line_notifier for these cases. The problem I have with this is that the graphic interface slows down a lot if, for example, you insert 4 notes at a time through OSC, with note_on note_off. In this specific case, this operation triggers 4 + 4 times the line_notifier (detects 4 + 4 instantaneous changes). On the other hand, if it’s just a note, it works fast.
Creating a function that involves accessing the note_value with iterations in the pattern seems to be too slow, too much entanglement. It would involve detecting any way to modify a note, either directly or by copying / cutting from the clipboard…
-- Access note column properties either by values (numbers) or by strings.
-- The string representation uses exactly the same notation as you see
-- them in Renoise's pattern or phrase editor.
renoise.song().patterns[].tracks[].lines[].note_columns[].note_value
-> [number, 0-119, 120=Off, 121=Empty]
And you absolutely need to avoid using an idle_notifier? Otherwise it could be built in a much ‘smoother’ way, but of course it wouldn’t be as predictable/linear/instant.
If you’re doing something “crazy” like iterating a LOT of lines on each new note (for example, for finding out its note duration in a piano roll), I would seriously consider implementing a song caching system. It’s too complex for me to discuss here though
And you absolutely need to avoid using an idle_notifier? Otherwise it could be built in a much ‘smoother’ way, but of course it wouldn’t be as predictable/linear/instant.
If you’re doing something “crazy” like iterating a LOT of lines on each new note (for example, for finding out its note duration in a piano roll), I would seriously consider implementing a song caching system. It’s too complex for me to discuss here though
I would have to experience it with a specific function. But I’m afraid I would not achieve a better result than the line_notifier. I think the problem is that the API does not offer an instantaneous way to detect a change of note, such as a note_notifier (something that is working at all times). I miss this very much. For example, if you use OSC, it is one of the few things that works in real time to insert notes (note_on, note_off). You can insert 10 notes at the same time and it is fluid (I suppose this would be the most extreme case).
All this gets worse if you have other functions with notifiers or timers, working, although they are optimized to notify only when necessary.
It’s potentially a lot “worse” than that. If you delete an entire pattern, you will get potentially hundreds of these notifications.
So it’s definitely a good idea to follow this rule : “if you need to it, do it later”.
Btw: I would like to see the line_notifier being expanded with something that tells me what the previous content was.
That would help immensely in determining the kind of action that was taken by the user.
Then the question would be: how to make a note change detection function, with “do it later” and only react when changing a note in the pattern? If there is a case in which several notes are changed almost instantaneously, that the function only reacts once.When you create a tool that shows many changing objects, these API details become very important.
It seems quite reasonable that the API should offer an instantaneous way to check a note change. It seems something even basic, since Renoise works with “the notes” continuously.
But I’m afraid I would not achieve a better result than the line_notifier.
That depends very much on what you want to do on every note.
Typical example: does three ‘simultaneous’ notes trigger two processings that are unnecessary. Like if you’re doing some fancy rendering/scanning per-track that gets updates on every note, and you get a lot off duplicate processing that wouldn’t be needed. In these cases an idle_notifier can save you a lot of processing power by only doing it once-in-a-while (0.1s).
But if indeed you need every note to execute something unique, an idle_notifier would only help in the sense that it would eliminate any noticable GUI hick-ups et c, at the expense of some latency.
Regarding the need for knowing the previous note data and exactly what has been changed, your only chance is to cache the pattern data and compare the line_notifier* to the cache before updating the cache.
