rafalcieslak / algaudio Goto Github PK

Curreny algaudio blinding looks for sclang in C:\Program\ Files\..., or /usr/bin/sclang. These are not the only locations of where supercollider might be installed. The launch window should suggest the user a sclang binary if it's found in one of many popular locations, but should also allow the user to manually select a path, both as a text entry and with a file dialog.

All text displayed in the UI looks like colorful noise when rendered on Linux using proprietary nvidia drivers. This is probably a problem with premultiplying the alpha channel when preparing text textures for rendering.

Currently creating a connection loop between sliders causes a stack overflow as soon as any data is passed within the loop. The solution would be to track (globally) which params were modified within a given stack base, and abort setting the same parameter again from within lower frames of the same stack base.

Parsing an xml file (either a path save file, or a module collection description) can yeild a large number of possible errors. Even if they are displayed to the user, the visiible messages are not verbose enough. These messages should contain at least the line and character numbers, and rapidxml error description. Calculating the line number is not obvious, though, because it has to be performed on the original string, not modified by rapidxml parser.

Some modules may take up a lot of space, especially if they have a large (32+) number of sliders (e.g. a harmonizer with many voices). On one hand, the user must be able to access all these params, but on the other it clutters up the workspace.

The proposed solution is to make most models collapsable. A button on the module GUI would toggle the GUI display between two (three?) states:

1. Full module GUI displayed, all sliders are visibile, module GUI requires a lot of space.
2. Partial module GUI display, only the most important sliders (e.g. base frequency) are displayed, the rest is completely hidden (though connections still work, they might be displayed as if they ended on the collapsed slider), the space required is significantly compressed.

Optionally, a third mode might be useful:

1. The GUI is completely compressed, no sliders are displayed, only the name and iolets are visible, thus the module takes absolutely minimum space.

This is Windows-specific. Dragging any window apparently floods the application events, and therefore it cannot execute any code, effectivelly locking any interaction, timers, sequencers, etc.

Currently file dialogs block execution, because calls to nfd are blocking. Instead they should be processed in a separate thread, wrapped in a LateReturn proxy, so that the app can continue running while file dialogs are present.

Currently using the mouse wheel and/or the shortcut keys to change zoom level uses the center of the screen as the zoom pivot. It would be handier to use it if the pivot was at the area the user is focused at, which is where the mouse pointer is.

SDL_ttf is to slow to use it for rapidly changing text on every frame. At some point it will be necessary to implement a custom renderer, which first caches a font by drawing all (required) glyphs onto a texture, and when asked to render a fragment of text it simply copies parts of the cache texture to target texture, which will be much faster than asking freetype for a bitmap at each character (SDL_ttf apparently does that).

At this moment, AlgAudio always asks supercollider server to use ASIO. The lanuch config window should present a list of available drivers, and let the user choose one of them as they wish. This makes no sense on Linux systems, as there is always one option to choose (jack server), but will be very handy on Windows.

Similarly, the number of input/output channels and sample rate should be configurable when starting AlgAudio.

A number of modules, including sequencers, will require access to a timed events source. Such timer should be one for all instances, as this simplifies management. It should be able to wake up the main loop and perform requested action when the timeout happens. The interface should allow scheduling one-time actions, as well as periodical events. Periodical events should be accesible via a handle which allows cancelling and period changes.

Possibly the timer managed might store all scheduled events in a priority queue ordering them in time, and waiting for the firstmost event.

The lanucher configuration should automatically detect where supercollider is installed (windows registry, PATH on *nix), but regardless of whether it was found or not, the user should be able to select any custom path.

Zooming-in at a more complex path (e.g. example3b) causes all wires to blink continously, apparently because of some incoherent draw mode being switched. This is affected by the canvas view position, some module guis, if are displayed within the canvas view, can cancel this effect.

Currently, only one alert /question message can be displayed at once. This means that when a new alert appears, the previous one is discarted. Not only it hides information from the user, but can also cause lockdowns, if a piece of code is stuck waiting for a response from the previous alert (which will never arrive).

The solution would be to display alerts layered on top of each other, in reverse chronological order. This way hiding one would reveal the previous alert, and no message would disappear without user confirmation.

Both the maximum and the minium value a slider can be set to should be configurable at runtime, and stored into save files.

The point of output mode params is that they are not settable, but simply represent a result of calcullations or analysis. This way it makes little sense to store them in a save file, because their value will be either deduced from other params by the module code, or will be instantenously modified by a sendreply.

It should be possible to copy/paste multiple selected modules. This should be relatively easy to implement, as storing to the clipboard can simply export the selection to XML, pasting requires loading from that XML tree and appending the parsed data to an existing canvas.

An optionally build target that produces a set of all libraries and headers that are needed for developing custom modules would make shipping algaudio for third-party module developers much easier. It will be also necesary to fully test the module development process with an external set of tools.

Sequencers should have a sync-in and sync-out data params, which would accept a fractional number representing the current sequence cue, so that multiple sequencers may be chained together to stay in-sync.

A new kind of wiring that transports MIDI messages between modules is needed. This would allow routing MIDI signal between modules. This way the MIDI signal could share targets (mutliple synths), sources (multiple inputs), and some specialised MIDI modules could be easily implemented (sequencers, transposition, note lookup, audio->midi).

The number seems to be a little random. Whenever I add the 52nd module to one of the module files, AlgAudio won't start, stopping at "installing module templates". Currently I've got 7 module files. The same issue appears when I merge them into 6 files with the same number of modules. At 52nd the program refuses to start.

When loading a complex path from save file (see example3b) all connections are restored in algaudio, but some of them are never created in scsynth.

Release builds have some compile-time optimisations enabled, but lto (particularly useful because 99% of algaudio code ends up as a single shared library) are not.