FoxDot Standalone

mcj · 6 June 2020 19:43

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)

tshrpl · 2 July 2020 22:58

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

mcj · 11 July 2020 09:56

Thanks!!!
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!

tshrpl · 18 July 2020 16:59

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.

jamshark70 · 19 July 2020 10:06

If you have concrete suggestions about how to improve this, please don’t hesitate to raise them on the SC user forum http://scsynth.org or as a Request For Consideration GitHub - supercollider/rfcs (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.

hjh

tshrpl · 19 July 2020 17:59

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

includePaths:
    -   /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
excludePaths:
    []
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: https://github.com/supercollider/supercollider/pull/5081#issuecomment-657206530

jamshark70 · 20 July 2020 03:40

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).

github.com/supercollider/supercollider

exclude default paths: change from command line parameter to language file flag

supercollider:develop ← miguel-negrao:miguel/topics/removeStandaloneSwitch

opened 09:38PM - 17 May 18 UTC

miguel-negrao

+123 -56

Before this PR: - default paths were excluded from the list of directories to …search for class files if sclang was started with -a command line option. - The "Exclude default search paths" option on the interpreter options in scide would toggle the use of `sclang -a`. with this PR: - An additional method is added to exclude the default paths excluded from the list of directories to search for. To turn on or off excluding the default paths the 'excludeDefaultPaths' key can be used in the YAML language file. - The reasoning behind this PR is that some language config files require the default include paths to be active while others require the default include paths not to be active, in order for the language to compile successfully, therefore it makes sense that that choice is made in the yaml file itself, so that it will work automatically. This way switching to a different language config file will also switch whether default paths are excluded or not. - The behaviour of `sclang -a` is kept the same. - The "Exclude default search paths" option on the interpreter options in scide, doesn't use `sclang -a` anymore, instead just mirrors the value of 'excludeDefaultPaths' key in the YAML language file. Before, with this PR the default paths were excluded for ALL language config files, now the choice is done in each YAML language file. - A getter and setter were added for excludeDefaultPaths in the LanguageConfig class library class. - In PyrLexer.cpp changes were made such that when recompiling the library the in-memory version of the LanguageConfig will be used instead of the version in the YAML file. This allows testing language settings by manipulation through the language (via LanguageConfig.sc) before writing to the file. An example config file that uses a Class Library other than the system one: ``` includePaths: - /home/miguel/Development/SuperCollider/supercollider/SCClassLibrary excludePaths: [] postInlineWarnings: false excludeDefaultPaths: true ```

… 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?)

hjh

tshrpl · 20 July 2020 10:12

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)

jamshark70 · 20 July 2020 12:22

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.

hjh

mcj · 26 July 2020 10:40

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

tshrpl · 30 July 2020 09:27

I need foxdot users to test this https://drive.google.com/file/d/1MdcnMv2GzReTB3tkM4I6Ej8-pZlbybCu/view?usp=sharing

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