2D animated and navigable score progress

[Xavman42]

I've been working on developing an animated score where the performer navigates in 2-D space interactively by choosing different paths. A small sequence of paths along which the player navigates might end up looking something like this.

I've figured out a decent way to animate motion along the staff-path here. Only when objects are in the render area do they become visible, which cuts down quite a bit on the overhead. Using numpy for storage, I can fit quite a few objects in the world and still render at a smooth frame-rate (barring the Windows 10 leakage issues I've been dealing with). The only thing I can't figure out is how to do is restrict the window size and remove the ability for the user to zoom and scroll the window. Also, are the built in staves scalable? If not, I can just work with image files for now (I'll upgrade to svg's soon.)

[ajyoon]

This looks so cool! We were definitely not anticipating use-cases like this so it's a great surprise seeing such an idea actually working. A few thoughts:

• The object culling is cool, but probably shouldn't be necessary since Qt does its own B-tree-based culling. Though I do see you're doing some manual rotation and translation work which is being performed at a higher level, so maybe it does make sense for you.
• The preview window cannot currently be programmatically controlled. This includes things like disabling scrolling and programmatically translating or rotating the viewport. But these are actually pretty easy to add, so I'll try to throw that together in the next week.
• Are you planning to have user input like keystrokes control the score? Have you tried doing that yet? I don't know how or if it would work, but I feel like it might require hooking into the Qt runtime in a way we don't currently support.
• Staff size can be set at init time with the line_spacing argument. I don't think there's currently a way to adjust their size after init. If you do need something like that, and you aren't using all the fancy stuff Staff supports (as currently seems to be the case), you can always just roll your own staff with a Path.

[Xavman42]

• If I will be able to rotate and pan the preview window in the near future, I'll overhaul pretty much all of this. I do want to control some of the culling though - there may be some interactive elements which I want to manually instantiate. But if I'm able to rotate a Qt window, that should cut out a lot of mathematical overhead.
• There will be some user input, yes, but no more than one or two keys. I've had great success with this basic function for keyboard input:

import keyboard
def keyboard_input():
    keyboard.on_press_key("up arrow", lambda _: print("Up"))
    keyboard.on_press_key("down arrow", lambda _: print("Down"))

I don't need threads or anything! All the user will have control over is the direction the player moves at a staff-intersection, so I'll just return something like 1 or -1 to change rotation direction. The part I'm worried about is getting this to work with a foot-pedal or something like that.

• If I were to make any feature request, it would be to allow staves and their children to rotate. If I had that, I would happily work with the pre-made staff class!

[ajyoon]

I'm nearly finished with the window controls, including viewport translation and rotation, so we should get that released in the next couple days. Great to hear about keyboard input, I was afraid Qt might be intercepting the keystrokes! Many footpedals dispatch MIDI or regular keycodes, so I think it shouldn't be a big issue.

Regarding object group rotation, unfortunately that's not in scope for a while since it's a pretty involved upgrade. We're tracking it, along with more robust rotation in general, over at #9. If you're interested in contributing to this we would be very happy to support the effort.

[ajyoon]

Hey @Xavman42, we just released 0.1.2 with a bunch of new features that should cover your use-cases (except the object group rotation things). Let us know what you think!

[Xavman42]

Works great so far! The only thing I can still use to move the viewport after using auto_viewport_interaction_enabled=False is the arrow keys, but I can work around that. Thanks a bunch!

[ajyoon]

The arrowkey bug should be fixed now in 0.1.3 which I just released

[Xavman42]

The updates have been very helpful! I'm well on the way to realizing my score-idea how I'd imagined it. (Please excuse my sloppy, non-optimized code!)

[ajyoon]

looking great!

[Xavman42]

Things are coming together...
I recently realized that I can use python multiprocessing to spawn multiple viewports. This way I don't have to waste any effort making the HUD glue to the viewport as it moves around!

[ajyoon]

looking great! i'm surprised the multithreaded HUD works

[craigvear]

Awesome.

…

Sent from my iPad

On 10 Jan 2023, at 17:40, Xavman42 ***@***.***> wrote:  Things are coming together... I recently realized that I can use python multiprocessing to spawn multiple viewports. This way I don't have to waste any effort making the HUD glue to the viewport as it moves around! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.