helper functions, aliases and Strudel extensions

[larkob]

Here's the thing: I'd like my audience (at least the musicians in the audience) to be able to follow along and understand what I'm doing and how a musical piece works. The same is true for myself: When I watch someone perform music in live coding, I want to understand it. Otherwise, what's really the point of showing anyone the code if it's not comprehensible?

An important aspect of this experience is that the currently playing parts of a pattern are highlighted, so I can make a relationship between what I hear and what I see. Another aspect is that the code itself is more or less self-explaining. As long as I use functions like velocity, gain, every, silence, etc. the code is easy enough to follow, but when I use functions that require knowledge of JS or Strudel, my audience won't be able to follow what's going on. So, what I'm really looking for is a way to express my musical ideas with well-named functions and to abstract away anything that'd be confusing for the audience.

Basically, I want to write semantically meaningful aliases and helper functions - which I can do already. However, there's currently two approaches I can see, which both have their drawbacks: I can put my extra code in the REPL for everyone to see, but then it becomes very large and unwieldy. Or I can put it in the prebake file, but then it only works on my own server. However, I want others to be able to copy and build on my Strudel compositions (because I also want to write tutorials/guides), so there should be a way for others to copy and inspect this extra code.

My idea is this: how about we allow for this kind of extra code to live in "gists" and have a dedicated area in the REPL where I can add the link? Kind of like I can add external scripts in codepen, jsfiddle, etc. The important part here is that this link should be an intrinsic part of the song, so when I copy the Strudel URL (or use the "Share" feature), it's doesn't get lost.

I'm also aware that using aliases and helper functions comes with a price: People wouldn't be able to find my functions in the official Strudel documentation. But, perhaps, there's also another way: What if we allowed for sth. like "extensions"? I'm thinking about sth. like Lo-dash, which also defined lots of helper functions like flattenDeep that later made it into native JS. So, imagine Strudel offered a way for people like me to contribute an extension file to the Strudel repo (sth. like the prebake file) and then the REPL would allow to enable/disable these extensions. Any extension should of course also have proper documentation. And these extensions (whether they are stored as gists or as a file in the repo) could also be used to define sth. like "prepared environments" focused on sounds or effects.

[yaxu]

I think the aim of having well-named functions is fine, but I also think it's important to recognise that the notation is not the music. They live in very different worlds, and you might end up abstracting away everything that's interesting about algorithmic patterns and end up with a simple sequencer that would be better as a GUI.

That aside, the idea of supporting extensions and dialects is good!

[felixroos]

Thanks for opening this discussion! What you want is already partly supported:

gist

My idea is this: how about we allow for this kind of extra code to live in "gists"

That's already possible (though undocumented):
https://strudel.tidalcycles.org?ZY76BWx967ty

have a dedicated area in the REPL

I am generally cautious about adding dedicated areas, as all state should live in code (which also makes it shareable).
In the future there will most likely be a sidebar with dynamic documentation and probably also some ui for code insertion, where we could potentially put a "add gist", but that's not a critical thing for this feature atm i think.

I can put my extra code in the REPL for everyone to see, but then it becomes very large and unwieldy

As an alternative to a gist, you can also write your unwieldy code at the top and insert some blank lines, then scroll down, so the audience won't see it.

packages

imagine Strudel offered a way for people like me to contribute an extension file to the Strudel repo

You can already create a new package to add extra features + send a PR to add it to the strudel project.

the REPL would allow to enable/disable these extensions.

To make it available in the REPL, you have to load it inside App.jsx, so there is currently no opt-in, but it would be possible to add a function likeloadPackage('package-name'), which will do

evalScope(import('package-name'))

I am not sure if it is always the best way to create a package though, because

• it is not the easiest thing to do for someone who does not work with npm regularly.
• you need a full dev setup with the strudel project forked, or some custom project that imports strudel (no example for that yet)
• the package needs to be published to npm, probably under a custom name like strudel-xxx (we cannot give everybody access to the @strudel.cycles npm organization

scripts

It might be simpler to have something like loadScript('...') which will load a script from an url and add it to the scope (similar to hydra). This is like gist but it allows any url to be used. But it's also kind of scary to import some random code and execute it, without being able to see it instantly (same with gist).

plugins

Another idea would be a separate plugins folder where anyone can add a file with custom code, which could be loaded with loadPlugin('xxx'). With this, the code is

• unlikely to be harmful (PR has to be accepted)
• easier to write (no package publishing)
• executed only when explicitly loaded (opt-in), which increases the chance of getting merged.

In the end it also depends on which features one might want to add, it also challenges the maintainers to decide which features fit into the main repo and which ones should be separate packages / scripts / plugins. As this project is fairly new, we have not yet found definitive answers to those questions.

TLDR;

What already works

• gist TODO: document
• alternative: inline everything, scroll down
• add new npm package, load it by default

What could work

• loadPackage: load npm package
• loadScript: load script from url
• loadPlugin: load script from plugins folder (naming could be different)

[larkob]

Excellent! I really like the gist feature, it also works in the mini-REPL, which makes it particularly useful for me to hide away some stuff that doesn't matter for the particular thing I'm trying to explain. So, all good here !!! (And what a great collection of drum machines!)

As for extensions, I agree that packages are too hard (for me at least). The plugins approach sounds good to me. I just don't understand how the opt-in would work. I mean, either the functions are available or not, right? I still don't quite understand this whole vite approach, I've only used nodejs for backend stuff, so the concept of webpack/vite etc. is still quite alien to me. I guess, the loadPlugin would set some kind of "feature flag" and the extension would not be called unless that flag is set?

Perhaps it works more like a GUI control: I would imagine the page (both REPL and and the Tutorial with mini-REPLs) would show a little form with a checkbox and a named link for each available extension. Clicking the link would open the extension's content in a window or modal, so users could read the code. And when pressing Play, the loadScript (or gist) function would check if the checkbox is set and not load otherwise, so users have both transparency and control.

Another question about extending Strudel: Before I jump in, create some new function/feature and submit a PR - should I present/explain my ideas in a Discussion first (or an Issue tagged with "enhancement")? As you can tell I'm quite new to Tidal/Strudel but have lots of ideas I can't wait to experiment with ;-)

[larkob]

It just occured to me: Clicking a checkbox could actually immediately load the script into the browsers scope, which would then make it available in the REPL (or all mini REPLs) without even needing a gist or loadScript command, right?

[felixroos]

I just tried out loadScript: https://strudel.tidalcycles.org?TO3z8wnvE2p3

so this is basically like gist, but allowing any url.

I just don't understand how the opt-in would work. I mean, either the functions are available or not, right?

Using eval (or better safeEval), you can always load stuff on the fly. I meant that plugins will work just like scripts, with the important difference that they are part of the strudel repo, which makes them trustworthy (malicious scripts won't get merged). loadPlugin(name) could just call loadScript(`./plugins/${name}.js`).

e.g. loadPlugin('test') would then eval https://strudel.tidalcycles.org/plugins/test.js on the fly.
But I am still not sure if it's a good idea to go that route.. If we do, we might even forbid loadScript/gist so malicious code could only be written inline, where it's visible without checking an url

Perhaps it works more like a GUI control

I would avoid standalone GUI controls when possible, as it complicates a lot of things

Another question about extending Strudel: Before I jump in, create some new function/feature and submit a PR - should I present/explain my ideas in a Discussion first

Sounds good!

[larkob]

I would prefer loadScript over gist because it gives users the full URL, making it a little bit easier to inspect the loaded code. But what if we could turn the URL into a link that users could click and open in a new window? I noticed that everything is put into <span> tags with different classes, so there must be some way to detect that this not just a string but an actual link (starting with 'http') and then it could be put into an <a> tag.

[felixroos]

it seems clickable links are not possible with content editable (which is what codemirror uses), see https://discuss.codemirror.net/t/decorated-a-tags-nor-treated-as-links-by-browser/3664, but an icon might do the job, let's keep an eye on https://discuss.codemirror.net/t/avoid-replacing-match-in-matchdecorator-decorator-to-add-link-icon-after-urls/4719

[felixroos]

and yes, I also prefer loadScript over gist for that reason