Using codeswing to support a LED display emulator

[qix]

Hi there,

Firstly thanks for your work here! This project is very close to what I've been looking for as I try build out an editor for some of my LED projects. Since uploading to the wall takes ~30 seconds having the emulator makes it much easier to build out patterns. Here's an example one I built for the new year: https://www.facebook.com/509819936/videos/10160610832109937/

I managed to get everything hacked together and working in CodeSwing. The code (both a swing and the extension that implements codeSwingCompile) is here: https://github.com/qix/light-swing

It required a bit of reverse engineering since there were no actual examples and the documentation was often misleading. I'll send a pull request with some tweaks there, but an example extension would be super handy as well.

In order to make this really great I have two feature requests that are intertwined. I'd be happy to help work on them but realize it may be quite a deviation from your plans so would be worthwhile to have a discussion first:

a) Support for multiple files. At the very least for this project I would like two files. The lighting script (which is currently the index.ino file) and the coordinates of the LED lights (which is currently hard-coded into the extension, src/points.ts). Since these two files would need to be combined to form the output page the current API for codeSwingCompile would not work. I might be able to hack it having the points file compile down to CSS, but that's not really ideal.

b) Support for codeSwingCompile inside the swing This one is not as major if you're strongly opposed, but I would much rather have my instructions be Install the codeswing extension and open this workspace. The actual light-swing parsing and compilation would be put into a normal JS package, which codeswing.json might reference.

I'd imagine the API to be: codeSwingCompile(files: { filename: source }): { html, css, script, input }. That API would also allow multiple input .ino and .h files. If everything matches what is already displayed only the checkInput method is called. Since this is an advanced use case obviously some of the other features such as CodePen export would no longer work.

Thanks again! Let me know your thoughts.

[lostintangent]

Wow, this is unbelievably awesome! 🎉 I apologize for the docs not being great. I've been largely optimizing for end-users right now, and so the extensibility documentation is definitely lacking 😞 I can take a stab at improving those, but of course, any PRs would be extremely welcome (since you also have "fresh" eyes).

Regarding #1: which files do you want to be visible when you open a light swing? Just index.ino?I just ask since you mentioned points.ts, and I wanted to confirm if that was a file you expected users to edit, or if it was simply necessary for the built output. I think your request #1 below makes a lot of sense, and I just want to confirm that I fully understand the intended user-experience 👍

Regarding #2: would it be sufficient for now, to have the light swing extension declare an extension dependency on CodeSwing? That way, you could instruct users to install light swing, and they'd get CodeSwing automatically? I like the idea of the codeswing.json file declaring NPM packages that it needs, which could include a custom language compiler. However, there may also be benefits to you having a custom VS Code extension, since that might enable other custom experiences (e.g. you could expose a command to deploy the code to your device?).

I also noticed that you're using the "input" feature, which is cool to see. I created that as a bit of a proof-of-concept, and so I'd love to learn a bit more about your use case here. Does the index.ino file include the code to define the light animation, and you're using the input file to instruct the swing about the specific animation it should run?

[qix]

Forgot to send through the PR with the minor changes, just did so.

I think for the swing it'd make sense for index.ino and points.ts to be loaded. Basically at-least for my own LED setups I would keep one CodeSwing for each one, and each of those has a different points configuration. It's basically equivalent of a stylesheet I guess... won't be edited often but useful to show it as an input. My ideal layout would be all the source files (.ino or .h) in the top left, the points layout (points.ts) in bottom left, and the display on the right.

The more I think of it I think the extension is actually the right way to go. It would be neat if I could have an extension requirement in the codeswing.json and have CodeSwing complain if those requirements aren't met. The inverse can be done with extension dependencies.

As for the input system, "in production" my lights function off events that are sent to the devices. I emulated that with the input system... but the code editor view is far from ideal. I think my ideal would probably be having an input.html that could have a more sophisticated form to send messages to the display tab. My main problem with the input system as it is, is that the displays typically start off and only light up when they receive an event... the current input system only sends it on change, so after every source file edit I need to manually trigger the event. I can hack that by adding the event to my codes setup() function but then need to remember to remove that before deploying.

[lostintangent]

I wonder if we could leverage the existing config support for your points.ts file? Right now, if your swing has a config.json file, I'll load that and inject it into the preview as window.config. I could potentially add support for config.js/config.ts, that would execute the file, and expose its default export into the preview as window.config. Would you be able to make that work? I suppose you'd need to move some of the helper functions from points.ts to your stdlib?

Beyond that, I could add support for customizing the name of the config file, and defining that you want the config file displayed when opening the swing (both as settings in codeswing.json). That would allow you to call the swing points.ts, and have it be automatically opened when you open the swing.

Thoughts? If that proposal would work, it would be pretty straight forward to make the above changes 👍

Regarding the input system: I could make a change to send the input value whenever the swing is run? That would presumably address this issue? Or, you could move the event into the points.ts file and make it a "config" setting that you read from window.config on every run?

[qix]

Yup that would work!

Having it executed is nicer, but honestly the solution of just pre-generating a config.json with all the point x/y coordinates is an acceptable solution here too. I'd only want it opened up if it could be tweaked live as well.

That would solve the issue for me, but it would be nicer to build some basic UI around it. For my specific case I'd probably want a dropdown list. I could move the initial event into the config file, but that one is going to be changed more often.

[qix]

The bigger (and harder) feature request is the ability to compile multiple files.

It's something that could differentiate CodeSwing from the online versions... since it's already built into a full fledged IDE. It might be specific to my use-case, but I'd imagine there are many more cases where the live editing across multiple files would be useful.

Last (unrelated) question- part of the initial reason I was excited by the CodeSwing idea was the first screeshot/movie you have is of the whole thing operating inside of a browser. I really like using VSCode for local development, but it'd be great if I could get it running in a browser too for demos. How did you do that?

[lostintangent]

Could you elaborate on what you mean by being able to compile multiple files?

Regarding the browser client: that's GitHub Codespaces, which my team works on. CodeSwing is meant to compliment it, which is why the GitHub org is called "codespaces-Contrib". That said, are you interested in the cloud IDE, or were you looking for a web preview of your swing in order to share with folks?

I just ask because I've been thinking about enabling a simple workflow where you could publish your swings to a GitHub repo, and use GitHub pages to view them.

[qix]

Compilation

If you look at the code that actually runs on the device, it's split into multiple files for readability: https://github.com/qix/light-swing/tree/main/particle-init

In order to work with code-swing I had to concatenate them into one giant file, and I usually just scroll down to the #include "main.h" line: https://github.com/qix/light-swing/blob/main/test-swing/index.ino

It would be great if the editor supported having all the source files as tabs in the editor instead of just the single index.ino

Codespaces

I'm mainly interested in deploying it as a demo. Using GitHub pages would be perfect!

[lostintangent]

Closing this as out of scope, since I haven't had much time to maintain this extension, and this isn't a core scenario for it at the moment.