FoxDot Standalone

I find FoxDot AWESOME! It saves a lot of time while coding music and it is fun!

It would be great to have it as standalone, with integrated Python and SC,
as for example Sonic Pi has SC and Ruby integrated.
(personally I do not like Sonic Pi)

i dont think most people need a standalone version, but yeah it will be cool … I will try to make a standalone version :smiley:

It would be great and it is worth!
You have right, when speaking about people with at least some programming and computer knowledge. Nevertheless, I teach music programming in the school and the children struggle with Sonic Pi (especially with synchronization) and its flexibility. They like better FoxDot, but with all installations, use and updates, they loose their enthusiasm.
When it was possible to combine sclang and ruby, it should be easy to combine sclang and python to have FoxDot as standalone. By the way, for my eyes, I like a lot the original color theme! I also adapted other IDEs to this color theme (only with background #002934).
Also, I am thinking on writing a help file, but musically explained, not mathematically, with traditional musical example as a result of the code. In other words, the path would be: code -> score illustration -> sound. I think this may be the reason why many traditionally educated composers do not dig into programming; but they could, with a musically based (traditional notation) help book.
All the best!

1 Like

apology for the long delay.

for the time being I’m just working on a linux version. compiling foxdot is fairly straightforward. But packaging up supercollider is a huge pain. especially because of it’s search paths which needs a complete redesign imo. so a portable version is pretty much impossible as of now.

If you have concrete suggestions about how to improve this, please don’t hesitate to raise them on the SC user forum or as a Request For Consideration (or as an issue on the SuperCollider main repository, but changing SC paths is far reaching and I think would benefit from the more careful discussion that occurs under an RFC).

The SC dev team is aware of SC packaging difficulties and would be receptive to suggestions. This is one topic where many people may have different opinions, so it’s unlikely for any one person to get it exactly the way they want, though.

SC developer Miguel Negrao has worked on a few improvements on this topic:

Note also that sclang has a “standalone mode” – you still need the class library and help directory structures, but you can force sclang to ignore system-wide default locations and use exactly the ones you specify. The difficulty is that these can’t be relative paths currently, but paths could be specified programmatically – if a hypothetical FoxDot installer written in Python knows the installation directory, it could generate sclang configuration JSON and a sclang -a ... script (I think it’s -a, I might be wrong) and it “should” work.

Also there’s scsynth -U to force specific UGen binaries to be used.

So there are options. It could be easier though.


yep, I’m aware of the advances the dev team has made in this regard

after going through their docs I figured out about the -a flag and trying to use that as a workaround. But so far I’m unsuccessful

This is what I’ve got till now.
sc requires a default build directory / installation prefix, in my case it’s ~/Desktop_3/test
here’s my config

    -   /home/iloveanime/Desktop_3/test/share/SuperCollider/SCClassLibrary
    -   /home/iloveanime/Desktop_3/test/share/SuperCollider/Extensions
    -   /home/iloveanime/Desktop_3/test/share/SuperCollider/downloaded-quarks/BatLib
    -   /home/iloveanime/Desktop_3/test/share/SuperCollider/downloaded-quarks/FoxDot
postInlineWarnings: false
excludeDefaultPaths: false

the excludeDefaultPaths has no effect for some reason, but -a certainly does.

I’ve made a wrapper python script which detects changes in the sc root direcory and updates the config accordingly. It also updates the $path to include /bin

This is should work, except it doesn’t because of missing UGen issues (when the root folder path is changed) which I’m working on right now. But even when it does, setting up jack will be a big problem for the newbies. So until SC devs port the code for pulseaudio it’ll be unusable.
related pr:

You can also set (in SC) Server.default.options.ugenPluginsPath = ["/path/to/plugins", "/path/to/other/plugins"] before booting the server. This will skip default plugin locations, so you’d need to provide a path for every top level directory containing the plugins you want.

The language configuration file doesn’t affect server configuration (and it shouldn’t – you can have one sclang instance controlling multiple scsynth instances, and in theory they could all be using different subsets of plugins – server configuration must be independent of language configuration).

… so, do keep it in the language configuration file, because that will be the new place to control it. (I think the -a switch will go away in the next release.)

True. (One thing that interested FoxDot users could do to help is to test the experimental PulseAudio backend for scsynth. It seems promising but it’s a big change, maybe won’t be ready for a very near term release. Probably this year though…? assuming it passes all checks.)

Actually I could ask you here: One of the questions about the PA backend has been – will users expect to be able to choose the soundcard in SC code, or go to the PulseAudio control panel for it? Or rather, would it be a/ very important, b/ nice to have, or c/ not a big deal to have s.options.device = "..." fully supported? (Obviously it would be good, but is it critical?)


I cannot speak for everyone, maybe a poll ?
for absolute newbies like me, it’s not a big deal

I’ve been testing the pr changes, so far there are no crashes and works with foxdot just like jack, if not better.
And my absolute favorite part is that I can play youtube in the background ^﹏^
also, now I can send the i/o streams directly to different tools instead of using pulseaudio-jack (lot of configs required, oof)

That’s already helpful, thanks. RtAudio (the programming library we’re considering to interface with PulseAudio) support for PulseAudio device selection might be fine or might not, depending on the Linux distribution… could release the feature sooner if it’s not critical.

In technical terms, “better than JACK” is unlikely. But it is likely that PA is a better fit for your needs at the moment – which is cool! That’s the reason why Luis proposed a PulseAudio version of scsynth.


1 Like

I apologize if I’m missing something, but:
Sonic Pi doesn’t require SuperCollider to be installed and is opensource.
Would it be possible just to take the same model of sclang integration and replace ruby scripts with python?
All the best

I need foxdot users to test this

edit: linux only, uses pulseaudio pr of sc as backend …