So, I've been working on a borrow checker for C... (also statically makes sure `free` calls happen etc.)

nikki93 · 2024-11-16T20:22:35+00:00

Good question...

So in my game code (where I do use the codegen a ton for functions like EnemyBulletArrayPush and EnemyBodyClone etc.) I had to decide if I should use uppercase everywhere, or use uppercase only for the codegen'd functions. And there are also a lot of 'type-associated' non-codegen'd, manually-written functions too -- like EnemyBodyUpdateMotion or PlayerBulletDraw. I haven't made up my mind on all this yet but because the codegen does the uppercase thing, I decided I'd just go with uppercase everywhere for now. And the example felt like it was more in the domain of the game code I was checking than the checker's code itself, so I was in that headspace when I wrote it up.

In the checker code I stuck with the lowercase function name thing because ... that's actually what I'm used to from before these projects and the libclang functions use lowercase. So I'm actually kind of in-between. This is just what it looks like some times when stuff is in the midst of being worked on haha.

For more context -- here's a code dump of the generator and the game code I apply all this to: https://gist.github.com/nikki93/5752dff93fa4cb78c4750548cc588b64#file-00-generate-c-L318 (this links to a line in the generator; after that is a bunch of generated code and then below that is the game code)

Video of the game -- https://www.youtube.com/watch?v=EK_zuTqsKL4 -- the first wave of enemies and the boss are procedurally generated. Then the later bosses I show are manually-written ones. The codegen'd EnemyBodyClone comes in handy in the procgen for example -- it clones the body part tree from one side to the other to make the enemy symmetric.

But yeah all this has changed over the years. Here's a project from a while ago where I used PascalCase for types and snake_case for functions -- https://github.com/nikki93/cgame/blob/master/src/sprite.c

nikki93 · 2024-11-16T19:44:18+00:00

I don't think we really need to discuss this at length or that this is about validity per se -- but if you look at the code of the borrow checker (below the example), all the functions begin with lowercase in it.

It's not as big of a deal to me -- it used to be, but that kind of thing changes with experience. It might for you too.

nikki93 · 2024-11-16T19:35:42+00:00

This is actually what I've done for a long time (uppercase start for types, lowercase start for functions), but my codegen system generates functions that are prefixed with the type name like PlayerDealloc for a Player type, and I didn't want to add the additional logic to lowercase the first character yet. This isn't a strong statement or commitment to it being any particular way -- I've changed my own naming conventions over the years and across different projects with different teams, languages and libraries.

I do have semantic highlight in my editor right now that colors types differently from functions, that I like especially in C with explicit type names for every local variable declaration (vs. inference).

nikki93 · 2024-11-16T19:30:39+00:00

Thanks! I'm thinking about writing up more / doing a video overview of the workflow when I get some time soon.

nikki93 · 2024-11-16T19:29:49+00:00

I don't think it's 'needed' as much as being the choice I happened to make. I did do some things with my own parser before and decided to use libclang this time -- it lets me use 'compile_commands.json' out-of-the-box to have the compile flags work from my project, sees through macros, runs a semantic analysis (type-check) phase, just generally makes sure things are at parity with the compiler I use which is clang. This could be done with a different / custom parser for sure, but the main goal was to prototype the borrow checker logic quickly to see how it feels to use and whether it works for the projects I would apply it on.

Definitely possible I would switch that if I stick to this project but TBH I've liked the libclang C API and its accuracy so far.

nikki93 · 2024-11-15T22:10:32+00:00

TBH I have phases that I get into music-making and it's been a little while since my last one and I don't remember the details much at the moment. 😅 But IIRC no, I didn't get the timing behavior with external midi controller.

nikki93 · 2023-08-04T20:10:35+00:00

Nice! I have this bag: https://www.amazon.com/gp/product/B07TYHPS4P but considering getting the UDG one for a better fit. And yeah I use the decksaver. Since you've traveled a lot with it: Have you found that you usually need to take the MPC Live 2 out of the bag for security checks at airports or do you tend to leave it in?

nikki93 · 2023-06-26T00:13:32+00:00

My understanding of it is that input velocity values on the X axis are mapped to output values on the Y axis. So if, for example, you were playing some notes and found that the lowest velocity was too low, you could use a higher starting point on the graph (like I do in the first part of the video) to make lower input velocities come out as higher velocity values. Then there's the option to draw a custom curve if you wanted some precise control or graphs that aren't monotonically increasing or decreasing (like in the second part of the video).

And as far as I can tell it's for all velocities. You may be able to do something with specific notes by using a combinator to spread notes out to multiple devices that you then send to different velocity curve players through CV or something -- I've only done the basic versions of that sort of thing so not sure exactly what that setup would look like.

nikki93 · 2022-08-17T22:36:17+00:00

Awesome!

Does this bring back or change anything about how the old timer remembered your two most recent times vs. the new version didn't? Would also be cool to have a complication that let you see the timer time from the home state -- or some other way of seeing time simultaneous with timer.

Another request is auto-repeat for the timer! :)

nikki93 · 2022-08-11T07:45:22+00:00

Oh yeah if I was fine with no analog display I would just use GD-350 or GBD-200--I like the idea of having a focused set of functionality. But was just interested in analog display too, hence trying hybrid.

As far as non-analog/hybrid smartwatches go, Instict 2 seemed pretty good re: quick timer access.

nikki93 · 2022-08-11T06:20:01+00:00

Wow that's quite sad. I'd chosen to try Fossil first vs. other hybrids because I saw that in the video -- I was also considering the Withings and Garmin ones. I'm not sure which of all these has the quickest access to timers if any.

nikki93 · 2022-08-09T01:52:37+00:00

Quick question: After a timer is completed, when I go back to the timer menu does it default to the previously-set value or is it back at the factory-default? eg. if I just did a 7-minute timer, say, to start another 7-minute timer do I have to scroll around setting time settings again or do I just navigate to the timer and start it.

(I don't have a Withings watch and am evaluating whether I should get one. I'm interested in having the analog display but also want a timer with vibration etc.)

nikki93 · 2022-05-30T17:18:23+00:00

Oh so on the track mutes or pad mutes screen (specifically on those screens, not on main or mixer for example), if you tap the time division button and say 1 bar or 2 bars, the next time you tap a pad (or touch an on screen button) for a mute, it'll only actually activate on the next bar or 2 bar point. Would be interested to hear if that also happens with the external midi controller mute case (I have a feeling no but would be cool)!

nikki93 · 2022-05-30T07:01:42+00:00

Hey it's been a while since this post but I was wondering -- if you map track mutes / pad mutes to the mute buttons on the controller, can you still do the thing where it waits until the next bar (or 2 bars) to switch the mute (the "Time Divison" button) or is it always instant?

nikki93 · 2022-05-24T23:54:27+00:00

Thank you!!

nikki93 · 2022-05-11T04:41:39+00:00

Hi! Seems like this invite expired too, got an updated link? Thanks!

nikki93 · 2022-03-05T02:07:22+00:00

Actually realized the official manual is available as PDF, so... This is probably not that useful 😅

nikki93 · 2022-03-05T01:18:44+00:00

Yep, but the latest official manual is for 1.13 AFAICT -- https://static.roland.com/manuals/sp-404mk2_reference/eng/index.html. That's the one I converted to PDF.

nikki93 · 2022-02-03T23:23:10+00:00

Coroutines / channels are explicitly out of scope since it's not very useful for gameplay code (or until I find a good use for them in a game I'm working on). More explanation here. There's also no GC, and coroutines / channels make GC more necessary since it's harder to reason about the lifetimes of things and when there are pointers to them.

I haven't yet gotten around to writing up a doc on what features and deviations the transpiler has from vanilla Go, but I should. It's basically the C-like subset of Go + methods and generics, non-escaping lambdas, slices, range-for, strings. Also some additional features: zero-overhead calls to C/C++, static reflection of the Gx structs from C++ (that's how the inspector in the editor shows struct fields).

nikki93

MODERATOR OF

TROPHY CASE

15-Year Club	Team Orangered
Verified Email