Hi all please join discussion of the shape of future development efforts here: The Future of SuperCollider Development Efforts
1 Like
The following is my attempt to do that. It is written as a function and should be revised. The code structure is not so elegant and it could not be so optimised for CPU and memory usage:
I realised that a common convention for writing musical notation should precede musicXML export while doing this attempt.
1 Like
It would also be nice if the post window could post multimedia data such as plotting, rendered music xml, web page, video, image, etc. Would this be possible?
The console is a text interface. Why would it need to render a web page or play a video!? Do you know of a terminal that does this?
Of course, there are situations where you want to plot, render music XML, show a webpage or play a window, but this should be done in the GUI (= graphical user interface)!
Experimenting with the sclang kernel for Jupyter suddenly brought this question to my mind.
This got me thinking about jit.pwindow and jit.window in Max as well. The Max console can only print text, of course. However, one can use rendered video and graphics within a patch. This led me to ask this question.
No. I only know that one can make the terminal background transparent in some OSes, and one can put a video behind the terminal window.
Not very often, but still, I should press alt/cmd + tab to find the window that sclang calls to move to the SC-IDE. This seems to lead me to the question…
Even if it were possible, it would be really hard work to implement. I should have thought of that before I wrote it. Sorry…
No, but I’ve come across some very useful “pretty-printing” functions. Specially for trees and arrays. Array boxes in APL is a thing of beauty, for example, and it works with be most complex structures. Since sclang borrowed some array operations, it could also have those goodies as well, why not? The same for trees.
┌────────┬────────┬────────┐
│1 2 3 │4 5 6 │7 8 9 │
├────────┼────────┼────────┤
│10 11 12│13 14 15│16 17 18│
├────────┼────────┼────────┤
│19 20 21│22 23 24│25 26 27│
└────────┴────────┴────────┘
┌→──────────────────┐
│ ┌→──┐ ┌→────┐ │
│ 1 a │abc│ ↓1 2 3│ │
│ - └───┘ │4 5 6│ │
│ └~────┘ │
└∊──────────────────┘
Julia’s benchmark is another good example (unicode though)!
julia> using BenchmarkTools
julia> @benchmark sort(data) setup=(data=rand(10))
BenchmarkTools.Trial:
10000 samples with 968 evaulations took a median time of 90.902 ns (0.00% GC)
Time (mean ± σ): 94.936 ns ± 47.797 ns (GC: 2.78% ± 5.03%)
Range (min … max): 77.655 ns … 954.823 ns (GC: 0.00% … 87.94%)
▁▃▅▆▇█▇▆▅▂▁
▂▂▃▃▄▅▆▇███████████▇▆▄▄▃▃▂▂▂▂▂▂▂▂▂▂▂▁▂▁▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
77.7 ns Histogram: frequency by time 137 ns
Memory estimate: 160 bytes, allocs estimate: 1.
1 Like
Hey @prko
Yes, this kind of idea would be great in a Jupyter notebook. But terminals don’t do this kind of thing, that’s why there are notebooks nowadays!
1 Like
There are some interesting possibilites when thinking of wasm as a general platform not just for scsynth/sclang but also for the IDE.
If one could dream, I think something like egui could make a nice basis for an IDE 2.0 (see demo egui – An immediate mode GUI written in Rust) or replacing QtGUI.
This would allow to really think of an IDE more as a desk where multiple snippets and windows can be arranged next to each other, multiple people can work on the same desk, integrating visual representations, sources and feedback - video playback in IDE within a document? No problem.
It would be a new way of thinking an IDE and not just in such a boring manner like vscode does - and it would immediately run locally or distributed in the browser in similar performances (this is not electron, it is native machine code!). Combind with the LSP it would create something really refreshing and creative 
4 Likes
Maybe something like SmallTalk? There is a history around those good ideas.
3 Likes
@dscheiba do you have the skills and time to do it? I’d love to see something when there is a prototype.
It may be pragmatic to have a pop-up window that works as a post-window from the current mouse position or from the block of code being evaluated, appear for a while when evaluating a block of code, and then disappear when the mouse pointer is moved, something is typed, or the cursor is moved.
A converter that converts the current output value of a Ugen to a float or integer when a trigger is received might be practical? Then we could be more flexible:
This would mean re-integrating the control layer into the DSP loop (where the whole design of SC3 was to get the control layer fully out of the DSP loop – which gives us benefits such as glitch-free buffer loading, which AFAIK Pd doesn’t have).
SC4 would be an opportunity for a radical redesign – a really radical redesign would be the only way to implement this suggestion.
hjh
1 Like
The synchronous nature of Pd (that is alternating DSP and message passing in a single thread) does not prevent asynchronous commands! There is just no good API for externals - yet : New asynchronous task API by Spacechild1 · Pull Request #1357 · pure-data/pure-data · GitHub
For [vstplugin~] I currently use my own task queue to enable asynchronous (glitch-free) plugin and preset loading.
The general problem is rather that users may perform arbitrary operations on the control layer, so there is no upper bound for CPU usage. Pd uses a ringbuffer to accomodate CPU spikes, at the cost of additional latency, but this only helps up to a certain extend. For example, nobody is stopping you from iterating over a 10 million element array, in which case you either break up the loop and distribute it over multiple DSP ticks – or you accept that you will get a drop out.
Often wondered if you could use Julia to write synths and register them with the server on the fly. Julia has an excellent jit producing highly efficient code that often rivals c.
1 Like
This was JMc’s original idea for SC3 (“sc3d5” which was never completed), but it didn’t get off the ground because JIT technology wasn’t there yet.
hjh
1 Like
Is the server built to accept new ugens while running? (I know nothing about this side of sc). Because getting a c pointer out of Julia is trivial
function foo(x::Int, y::Int)
return x + y
end
@cfunction(foo, Int, (Int, Int))
No because they’re loaded as dynamic libraries. It could be written to monitor for new libraries, or alternatively this is something a custom ugen could do (similar to what the VST3 plugin and Faust plugins do).
For Julia to be used for this you’d need some way for SuperCollider to call your Julia code. This would either require compiling it into a dynamic library with a C interface that matches what SuperCollider expects, or building some bridge code to Julia.
Doing this in any language that has a Garbage Collector is always going to be challenging. I’m not saying it can’t be done - just that it would be difficult and error prone. Sharing memory between GC languages and non-GC languages is difficult (particularly if the memory has to be used by a RT thread).