rocket / rocket Goto Github PK

While trying to use the editor on Mac, many of the commands overlap with Exposé which makes them not usable.

Support for Mac OSX specific keybinds or a way to remap keys would be ideal.

I'm trying to write LUA bindings of rocket and was not able to expose set_io_cb to the LUA-side for the following reasons:

1. Why does save_track not use the device io callbacks the same way as the read_track_data? This looks like an oversight and the sync_io_cb should have method write too:

2. I would need a way to pass userdata to the io callback (void *). I would need this for making a LUA-bindings of the rocket, as when I make the call back to LUA, I need a pointer to lua_State*, which gives access to the LUA virtual machine instance.

I think it could be even the same cb_param as is passed to the sync_update, but I'm not sure if it would be better to be a separate parameter:

The cb_param would have to be passed to any functions that do I/O.

I sadly no longer have the time and motivation to actively maintain Rocket, and it's unlikely that I'll find that time and motivation anytime soon. I suspect this has been evident from the lack of activity for a while. But I would love to see this work continue, so it would be great if someone else were interested in picking things up.

I'm not planning on entirely stepping away anytime soon, I'll be around to help review merge-requests etc. But I'd love to have a bit more of a contingency-plan here. But I do plan on stepping down from the maintainer role in the long term, given that someone steps up to the task. I don't want to get in anyone's way ;)

It's a small project, so the task isn't very big. It's mostly about providing code-reviews and merging once things are ready, producing releases and tending to automation.

Any takers? If so, please let me know by posting a reply here.

In js-version at file syncdeviceplayer.js there is one function call (track.sortIndex()) that should not be there as the function does not exist in the newest version. This causes crash when playing in demo mode. Just removing the line should work.

https://github.com/kusma/rocket/blob/master/js/src/syncdeviceplayer.js#L61

This was touched upon in discussion of #99 and seems like a prerequisite before we can land anything in that vein.

@kusma do you think abusing SET_ROW for negotiation is still the best path forward? Care to clarify how that would work if so?

This is intended as much as an [RFC] as [RFE].

In my use of Rocket I generally have autonomous driving of variables which are also exposed as rocket tracks. It's becoming increasingly apparent that I could use the ability to take over and surrender Rocket-control of the variables on a row by row basis.

For example, I might have something like a light source that in the code has some continuous functions like sin/cos combinations varying the orientation with time. But then at some point I'd like to override these values briefly to explicitly orient the light in time to the music, before again giving it back to the continuous built-in function. It'd be great if when sync_get_val() on a given track returned NaN I could let the continuous function take over.

As-is, this is at best achieved (AFAICT) by just reserving some magic numbers that work as such for the variables in question.

But floating point variables already have something special that all the code can just recognize without having to constantly reserve snowflake variables applicable to whatever is happening: NaN.

So what I'm envisioning is the row data would just have a NaN value and any such values are implicitly STEP interpolated with regard to their neighboring values, since they can't be interpolated. It's just the save/load routines that have to recognize something like "NaN" as the value instead of strictly floating point numbers.

Please correct me if I'm mistaken on this not already working, I just haven't seen a way to specify NaN values in emoon's RocketEditor and figured this hadn't been considered.

I'd also prefer if when a track has no rows present, sync_get_val() would return NaN instead of the 0 it currently returns. Which for my use would default to self-driven variables for unpopulated tracks... but if that's too breaking a change from current behavior, it's not the end of the world if getting NaN would require sticking at least a single row of NaN at the start of the pattern data...

This seems to be due to brew lacking QtWebSocket in their Qt-package.

Here's an example log: https://travis-ci.org/github/rocket/rocket/jobs/754631084

It seems like the real problem might be brew failing to update, but there's several things that goes wrong here:

• We're using an ancient macOS image
• brew cleanup gets automatically run
• ...which fails due to some shallow-clone shenanigans
• SDL no longer exists as a bottle
• We somehow don't notice the error-return from the brew update invocation...
• The qmake binary has moved?

So... ugh. Seems like things have bit-rotted pretty badly.

I don't have or care about macOS my self, so I'm not really very interested in fixing this right now. If anyone wants to pick it up, that's great. For now, I suspect I'll just disable the macOS build...

If utilized like in the example @ https://github.com/rocket/rocket/blob/main/examples/example_bass.cpp#L191 sync_tcp_connect() introduces potentially substantial stalls in the main loop.

For whatever reason, I've never noticed this in my Linux usage of librocket, the connect attempts seem to immediately fail if the editor isn't listening.. but these are over localhost.

Lately I've been producing win32 builds of a Rocket-utilizing project for my musician collaborator. He's observing significant stalls when the editor isn't running and our demo is attempting reconnects via sync_tcp_connect().

Looking at the code for sync_tcp_connect(), it's obvious why this is happening. (hostname resolution, blocking connect())

What I wonder is if it makes sense for us to just refactor how this works, so instead of repeatedly calling sync_tcp_connect() you would just do that once to put the sync_device into a mere logically "connected to host+port" state. Then transparently manage the actual connection within every sync_update() call, with maybe the sync_update() return value encoding the connect status (connection established vs. connection-in-progress vs. never told to be connected)

Then change the connect style to a non-blocking connect, with the expectation that sync_update() polls the status of the connection in progress... and restarts the connect if needed etc. But we'd never change the host+port mid-demo, it's just something you register into the device when you say it's a connected device, with the blocking name resolution happening only once at that initial make-connected-device call. That way it's a trivial matter of restarting the non-blocking-connect() process reusing the same resolved-host+port, whenever the non-blocking connect times out or whatever, from within the sync_update(), if a connected device.

I haven't given this a whole lot of thought, but it seems like something needs to be fixed here.

If I open a syncdata file and save it, the attributes in the XML row, value and interpolation are shuffled each time, and git thinks all keys in the file have been rewritten. This makes merging files a headache. Apparently, this is caused by QDomElement.setAttribute (here) storing the keys in a hashmap, which shuffles the keys on purpose (see here). This could be fixed by seeding the hash as suggested in the SO thread.

example_bass.obj : error LNK2019: unresolved external symbol _sync_destroy_device referenced in function _main
example_bass.obj : error LNK2019: unresolved external symbol _sync_get_val referenced in function _main
example_bass.obj : error LNK2019: unresolved external symbol _sync_get_track referenced in function _main
example_bass.obj : error LNK2019: unresolved external symbol _sync_create_device referenced in function _main
C:\Users\orange\Documents\Modern\rocket\Debug\example_bass.exe : fatal error LNK1120: 4 unresolved externals

Not sure what's going on here. I compiled the editor without much problem.

I'm not sure if I'm missing something here but Rocket's behaviour in between keys really bugs me. Let me present the problem visually:

I apologize for using Ground Control for the screenshot :)
I'd expect the first key to finish its interpolation and instantly change to interpolating the next key. But the curve seems to stay constant for a while which is very visible in some animations.

Is this the way it should work?

Since QT is a pain on windows, I'm continuosly having problem with running the app. Following this. I can't deploy the executable properly to run standalone, unless I'm not install the entrire QT platform. I've copied the dlls from the binary directory of QT, including the plafrom plugins. I've tried several folder structure for them (./, ./plugins, ./plugins/platforms/ ./platforms, ./platforms/plugins, ...)
I assume there is a method to compile these into the exe, and not using and dlls, but I couldn't achieve these. E.g. this one.

Do you have any suggestions?

It seems Travis CI no longer allows projects like ours, and just doesn't build anything.

We should probably move our CI to use GitHub Actions instead.

https://github.com/Contraz/pyrocket

Squeezed out in a day, but it does the job. Missing a few trivial things I'll fix in the next couple of days.

I see that the "COPYING" file contains an MIT licence (right?). It would be easier to find it if it were named LICENSE instead, but at the very least the license should also be referenced in the readme.

I'm also confused as to why it's name GNU Rocket when I don't see any relation to GNU and it's not GPL'd, as best as I can tell, so a quick bit of explanation around that might help other readers who are confused.

Thanks!

In my project that's a kind of meta-demo you interactively create and rearrange scenes through a creative process, the Rocket integration automatically creates tracks as the scenes are created/removed/reconfigured.

This mostly works already, but as the creative process progresses the tracks just keep accumulating, even those which are no longer needed. When using emoon's RocketEditor it even leads to crashes because the obsoleted tracks never go away and eventually break some finite assumptions. (I've already landed a fix upstream there to mitigate the crashing issue)

I'd like to add something like FORGET_TRACK to the protocol and library, which the Demo would send the Editor. It'd just have the track id as a parameter, as a way of reporting to the Editor "this track I previously performed a GET_TRACK on and we allocated this id for, I'm discarding it and all its rows from my internal state, any keys sent for this ID now I'll be dropping on the floor". If we had no interest in recycling the track id, that would be sufficient already just to get the Editor to reclaim the relevant UI resources/visual space.

Things get more complicated if recycling the track ids of forgotten tracks is desired, due to how the track ids are implicitly allocated via GET_TRACK like an AUTO_INCREMENT mechanism. For recycling I think we'd need an explicit RECYCLE_TRACK which would be like GET_TRACK with the addition of the track id # to be recycled. Then the subsequent SET_KEY storm would come back out with the named track's contents, using the specified track id. So the Demo would initiate the recycle from its side, by knowing it has a forgotten track id to put to use it previously sent FORGET_TRACK for.

I haven't coded up anything in this vein yet, but I already have a substantial project onhand that could serve as a test bed for this functionality without too much effort.

Curious what upstream thinks of this, before I go too far on the implementation side of this.