Oh! I will have a look. I introduced this issue in the Pulsar plugin as well and thought I fixed it on both sides.
Yes, this is a known error, but I will fix that. I need to add a list of functions that should be ignored from the event highlighting. The value of the p function is not a pattern. But I treat every string (which is overloaded to create pattern out of them) as a Control Pattern and wrap the deltaContext function around it. But for p this results in a syntax error. Itās a real lightweight implementation and I am not doing any kind of parsing. Anyway having a lightweight solution with some intentional design flaws is still better then no solution 
maybe the next step could be to think about a better implementation on the tidal side, so that it will become easier to implement it in the editor side.
Ah, perfect, now I understand a bit better whatās going on. Yes, I see that the issue with p and deltaContext is expected given how the editor works: itās a lightweight implementation that doesnāt do full parsing, so p isnāt handled like a normal pattern. For those of us used to TidalVim, it would be more convenient if deltaContext were available, but this NeoVim version is lighter, and I can adapt to these changes. I think having this lightweight solution, even with some intentional limitations, is fine as long as itās functional. Cheers!
I confirm this about the first line. 
Thanks so much, this was the issue. Thatās silly of me. I think it would be cool to have a demo song in the repo so people could play around with it. I can submit that once Iāve had a bit more time with Tidal
@vlachaizle , @brepundtrep , @DavidZwitser , the bug with the first line should be resolved. Would be awesome, if you could try it out.
I just tested it and it works. Highlighting everywhere.
1 Like
works fine 
1 Like
@mrreason, I was looking at scnvim to use supercollider within neovim, and I wanted to start it when I ran :TidalLaunch. I added a user autocommand with the pattern āTidalLaunchā in the :TidalLaunch function that I then hooked into scnvim in my personal config to automatically launch supercollider with tidal.
I think this is an elegant solution for separating supercollider from tidal.nvim while still allowing everything to be done with one command.
If youād like I can submit this change as a pr
1 Like
Just on quick thought about this, and I would like to hear your opinion. Because I think I would like to try out scnvim as well anyway and you have an approach that sounds charming to me. I am just curious whether we should keep the currently in-build SuperCollider version or whether we should have both options or should we just support scnvim? I have no strong feelings here. And should be scnvim a dependency? I doubt that (but then we need a check here?!), because someone may wanna use the SuperCollider IDE.
WDYT?
I made scnvim start with a user autocommand thatās executed on the āTidalLaunchā pattern. If installed with Lazy and using the recommended settings, scnvim is only loaded for supercollider files. You either need to remove that from your scnvim configuration or you need to add scnvim as a dependency to tidal.nvim (which is what I did) which ensures scnvim is loaded whenever tidal.nvim is.
If you wanted to use the SuperCollider IDE you simply donāt add that autocommand to your configuration. In my personal config, I check to see that the environnment variable SC_NOAUTOSTART isnāt defined before I register that autocommand so that I can make that determination on a project by project basis. I do something similar for the bootfiles, though thatās a bit off topic.
I wonāt comment on the current SuperCollider support, I initially started using scnvim because whenever I tried to use it I couldnāt get it to work.
The more I became familiar with NeoVim, the more sens this makes to me. Thanks for creating the PR on GitHub and sorry for the long delay. To create an autocommand for āTidalLaunchā makes sense. It would be really awesome, when you could provide a small example in the README or at least create a first list for the available autocommands.
I indent to add more (like TidalHush) that I already use.
Of course, I can update the readme. I was thinking that TidalQuit should probably also get an autocommand, and Iām sure other people will have their own requests.
1 Like
I had a major success after some weeks of work to enhance the event highlighting! I really would like to receive some feedback, before I merge this to main. Please provide me some feedback in this thread: Improve event highlighting by using Tidals PlayState Ā· Issue #14 Ā· thgrund/tidal.nvim Ā· GitHub
Please try out the event highlighting with the tidal playstate (it's reliable, it's fast, it performs well and it will allow us at least strudel like pattern visualization! yeah! ā I run the highlights with up to 120fps without big issues on my machine). This works, because I receive the Tidal playstate with all time and event informations from stdout. I can calculate the events beforehand. All other methods used the the current state within a specific time and this live edge approach was hard to stabilize.
In the basic form you just need to add this in your tidal.nvim file:
return {
"thgrund/tidal.nvim",
branch = "improve-event-highlighting",
opts = {},
-- Recommended: Install TreeSitter parsers for Haskell and SuperCollider
dependencies = {
"nvim-treesitter/nvim-treesitter",
opts = { ensure_installed = { "haskell", "supercollider" } },
},
}
If you use your own BootTidal.hs, then you need to define a clock target like this:
let clockShape = OSC "/ping" $ Named {requiredArgs = ["clock"]}
let clockTarget = Target {oName = "clock", oAddress = "127.0.0.1", oPort = 6013, oLatency = ((3/10)), oSchedule = Live, oWindow = Nothing, oHandshake = False, oBusPort = Nothing }
tidalInst <- mkTidalWith [(superdirtTarget { oLatency = (0.15) }, [superdirtShape]), (clockTarget, [clockShape])] (defaultConfig {cFrameTimespan = 1/50, cProcessAhead = 3/10})
Otherwise the inbuild BootTidal is correctly pre configured.
1 Like
I updated the nvim plugin with the optimized event highlighting. Now I am able to use the internal TidalCycles play state. This increases the reliability and performance tremendously. You can see it here in action (no tone):
I will resolve the open Issues and write a blog post about this topic, to document my journey so far. But then! I am able to integrate TidalCycles pattern visualization, like we have for Strudel, in nvim I already played around with the possible pattern representation in a TUI and this is my prototype:
When I resolved these topics, then I will port my implementation to Pulsar (see Pulsar Editor Event Highlighting). But I am still so excited by these topics Stay tuned!
2 Likes
@mrreason Iāve been using your Tidal Neovim version with highlighting for the past few weeks and itās been really stable. Great work.
The sound freezing issue I used to have somehow hasnāt happened again, which is amazing.
Also, running everything at 120 fps adds an interesting visual feedback layer to experiment with, especially since Iāve been exploring TUIs quite a lot over the past few days.
Best
1 Like
Wow, thatās amazing 
thanks for the feedback, I really appreciate that! 
I wish you a ton of fun with the plugin!
Btw, this plugin development is my excuse to dive into the TUI world as well. Before that I didnāt took that to serious 
Thanks so much @mrreason (and @grddavies ) - this is something Iāve been so hopeful of happening ever since feedforward started experimenting with it.
It took a bit of trickery to get going for me (ubuntu 24.04) mainly due to the nvim-treesitter rewrite, but also due to me moving away from the vim-plug config manager to lazy.nvim (unfamiliarity).
It nvim-treesitter requires the manual install of a tree-sitter binary > 0.26.1 now (the one in the 24.04 repos is not new enough).
Iāve documented bits and pieces in a repo here if anyone else is facing similar difficulties - the configs are all there, itās only got this plugin in it at the moment, but I will be migrating the rest of my configs in over time.
1 Like