Rerun co-founder here. Rerun doesn’t have replay in the sense of you send messages in and can play back the same messages in the same order later. We have playback in the sense that you can play it back in the viewer. We also have apis for reading back data but its more focused on dataframe use cases rather than sending you back messages
Thanks for sharing and that makes me really happy to hear. Keeping Rerun simple to use and easy to get started with has been a goal of ours from the beginning.
> I think Rerun should actually make the timeline view just another "view"
This is something we've talked about on and off internally and mostly all agree it's the right thing to do at some point. I also think there is a lot of things we could do to increase the usefulness of the timeline view even further so glad you're getting alot out of it already.
> Also we already have infrastructure to log and for live telemetry streaming so we don't integrate with the SDK directly in the deployed software and instead just have an adaptation layer to take logs or live data and push it through the Rerun SDK.
This is actually quite a common case and we don't have the ambition to make the Rerun SDK be the perfect logging library for all usecases. We're trying to do more instead to make it easier write efficient adapters that run elsewhere in your infra for cases where using the logging SDK isn't the best fit. The recent `rr.send_columns` API is in that direction but there will be more in the future
When was the last time you tried it? This was the focus of the 0.18 release, which improved the situation quite significantly (see https://rerun.io/blog/column-chunks for details)
wow, this looks very promising! are the cardinality limitations also improved? (ie, if i throw 500 timeseries at it, does the ui handle things gracefully?)
also, how's api stability looking these days? it looks like none of my 0.16 test scripts want to run against 0.18?
The many entities performance is still not where we'd like it to be. We've made multiple improvements over the last releases so worth kicking the tires again but it isn't solved in a fundamental way yet. There is still some low hanging fruit available to speed things up for many common cases of high cardinality by expanding our APIs slightly I believe. Those can come sooner that a bigger architecture update so hopefully that will be enough for your use case
What I love about you guys is that when somebody asks for a feature, you never come back with “sure, maybe we’ll bolt that on”, you come back with “We agree! That’s why we completely rebuilt the thing from scratch to handle that legitimate and central requirement! And still we’re not satisfied!” It’s awesome!
Glad to hear you like Rerun and thanks for the suggestions!
> A little worrying for me that rerun seems getting more complicated and verbose and API changes frequently.
We'll unfortunately continue to change some APIs over the next few releases. We're working towards stabilizing the format soon and want to make sure it's in a form that will last.
Do you have any examples of changes you found to be more complicated? We've been trying to maintain the approach of providing a very simple high level API but then exposing more lower level APIs over time for more power and/or control. Would love to learn where we could be doing better there.
> The whole vizualization code can clutter algorithm/code that is begin debugged.
This is a bummer to hear for sure. One of the motivating experiences behind starting Rerun was how much system bloat home grown debugging and visualization infrastructure can bring. Any chance you could share examples that are less clean than ideal? (either here, discord, github or dm on any platform is fine)
I think before I could have just one line recording. Not a big deal if logging only one sensor but my code is logging a lot of sensors and variables and then overall there is a lot of rerun code around. Maybe some dedicated VSCode or Jetbrains plugin that would allow hide/unhide all rerun code would be also good workaround.
Regarding reason for integration with inkeep or docset is to make for AI better index up-to-date documentation so that it can provide less hallucinated response with older API
Just so you know you can log rr.SeriesPoint(color=(0, 0, 255), marker_size=1.5) in the same call as rr.Scalar(peak.value) if you want. You could also skip logging the rr.SeriesPoint altogether and include it in your blueprint (as a component override or default). That way you can more clearly separate styling from data. Either way I hear you on the added complexity. At the end of the day it came down to trading off simplicity vs expressiveness on this one.
Totally hear you on the "make it easier to have AI that doesn't hallucinate" thing. We should definitely do something in that area. Just haven't managed to get the cycles in to do so yet
Thanks! I will have a look. Another idea - I wish there was some more high level visualization API similar like supervision [0] but instead for Rerun and instead of implemented in python to implemented with rust with autogenerated bindings (so that can be used on native/mobile as well).
So that you can easily log common models result like mediapipe pose/face/handlandmark, object detectors etc. with just few lines.
Emil had already started egui long before we started Rerun. The immediate mode paradigm of egui also fits very well with how we wanted to archetype Rerun. In addition to that the GUI framework story in Rust is still quite immature which means you often need to be able to make changes to the actual GUI framework if you want to create a "cutting edge" UI heavy product in Rust. Not surprisingly you therefore see other Rust based apps build their own GUI frameworks for that same reason. There are some promising initiatives in the Rust world but we'd still make the same decision to build on egui today if we were to start from scratch.
Sorry to hear that. Mind sharing what it was you were trying to do? Most users find Rerun to be very fast when trying to do the things it was built for.
Honestly most of the things I would like food are very oriented toward research/sharing use-cases, which I realize that is distinct from a lot of your users, but can mean:
- Working with large remote datasets/clusters
- Needing to share visualizations with others [both interactive, and pre-recorded/controlled]
- Being able to easy switch between N runs to look at data/results over time
Concretely:
- Currently it seems you need to forward multiple ports, and for each new session you need to re-connect. My memory is foggy but I found it was a lot of hassle to just connect a thin-desktop client to a remote backend.
- The support for baked-html is great, but it has limits (namely I was hitting some size limitations) and it would be cool to have a server that can read rr files from disk and stream them on-demand [e.g., point to a directory and let the user select]
- Generally speaking, I found the workflow difficult to integrate to the typical ML setup. Obviously not a priority for rerun but I think a little improvement [like the point above] could help a lot.
- A built-in screen recording feature would be great. I spent a lot of time screen recording and re-sharing clips.
Again, these are mainly nitpicks, love the tool overall and have recommended it to several people.
Thanks a lot I really appreciate you writing this out! I'd say most of your requests are things we'd like to address in the future. Built in screen recording is a common request and something I think makes sense for the open source project. A lot of the other requests require a central service of some kind to achieve high performance and/or a smooth user experience so those fall into the bucket of what will go into our commercial offering.
