What is the easiest way to follow code for a given env: in NightDriver

[airnocker]

So far, I am just opening platform.ini, main.cpp, effects.cpp global.h, laserline.h, faneffects.h, musiceffect.h, etc., scrolling through each looking for highlighted code.

Is there an easier way to find all the "activated" code related to each env: ? Also, besides noting the names of the include files and looking in everyone of them)

And yes, I've read the README.MD and most of the code comments.

[robertlipe]

Confirming what you've suspected, It's not awesome as there are "configuration" bits scattered around. Your list probably wasn't intended to be exhaustive, but add effects*[ch] to that list as a key bit. You may not need to know this, but as a head on posts for others that may cross this and read this (like that happens...) there are a few really fringe bits that are configuration that are actually in places like the soundanalyzer.h[1]. Personally, I consider these bugs worth fixing, but haven't taken up the charge to convince the house this is the case and to actually fix them. I once started a project that would take apart all 42 (?) projects and at least make a list of which effects were included in each. That was a stepping stone to something cooler which I don't even want to tease, but won't since I kind of ran out of gas on that project anyway. I know I tried two approaches - one of generating a compile_commands.json and then groping the generated command line for the actual -D flags that were passed and then seeing which of those were known to be effects, but that's not comprhensive. Another attempt was to build and load each, then script the REST API to see what effects were REALLY availalble since so many of those small strip effects have several "effects" all in a single file and under one #define. The "right" solution probably involves a bit of both...and surely more. If the question is more about effecient code navigtion in a small, but non-trivial project like this, it's a good time to make friends with the relevant tools, like editors that dim out code that's not 'turned on' by given #defines, but this requires your editor know a lot about your build system. GitHub's code search is fast, but requires you to be online. It doesn't show you only the symbols currently active for any given build (it knows nothing about builds - it only knows what files are checked in) in a way that's click to glance through in the right hand column. I tend to use 'ack whatever src inc*' a lot in this project since I work a moderate amount offline. Editors with LSP integration help a LOT, but even those really need to know about the build system and relatively few can understand platformio.ini to help understand the kind of issues I think you're asking about. LSP is super handy though just for finding which overload is applied and such, though. I'll say that if you're doing your own effect development (I contributed several dozen, though most were not from scratch) you quickly reach a steady state where you have just the "hot" tabs open and don't need to go spelunking through the existing code. Conversely, if you're doing small edits, you quickly find the code you want and everything you need is all just right there. You're in kind of the awkward spot of trying to walk over a moderate chunk of related code and feeling overwhelmed by the code that's in headers that's conditionally included or not based on things that are created and interact in non-obvious ways. I was there. So it's kind of a chicken answer, but my best advice is to make friends with tools like a good editor and other navigation tools. I often edit this code in editors ranging from CLion (nice, but not inexpensive) to Neovim to Sublime and recent flirtations with Cursor and Windsurf, which can read platformio and then just use scripts to call pio for the actual build and upload. (After decades of fidelity with a favorite of the 80's, I'm having my coding midlife crisis and flirting with many other trendy young editors these days...) Symbol lookup and being able to jump between declarations, definitions, and callers/callees are table stakes in a decent editor these days and I resisted even that for too long. Good luck. [1] search for 'io_num' in soundanalyzer.h for this example. I "just" need to build a SPECTRUM to prove that I don't break that and then build the thing i actually want to build to prove that the web configuration works, so it turned into another "I wanted an apple pie and had to build the universe" thing that collapsed under the weight once I had my head around it.

…

On Fri, Jan 24, 2025 at 12:10 AM aldengaw ***@***.***> wrote: So far, I am just opening platform.ini, main.cpp, global.h, laserline.h, faneffects.h, musiceffect.h, etc., scrolling through each looking for highlighted code. Is there an easier way to find all the "activated" code related to each env: ? — Reply to this email directly, view it on GitHub <#685>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD37A3ZNRUJD5AZINLRD2MHKORAVCNFSM6AAAAABVY6O3WWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHA3DIOBWGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[airnocker]

Thanks @robertlipe . I did edit my original post and add effects.h but failed to include the .cpp.

If the question is more about effecient code navigtion in a small, but
non-trivial project like this, it's a good time to make friends with the
relevant tools, like editors that dim out code that's not 'turned on' by
given #defines, but this requires your editor know a lot about your build
system.

Platform IO/VCS does exactly this, which I mentioned in my initial post. That does make this a bit easier for sure but demands a lot of scrolling.

Thanks for your other suggestions as well.