Editing the code of an extracted custom node causes a hard crash. This doesn't happen with non-extracted nodes.

As part of Controls Part II, the current controls need to be redesigned to look more tactile.

With the current background, it's very difficult to identify the outlines of segments e.g. borders between windows, exit symbols of windows. A brighter contrast or background colour would be beneficial.

As part of Controls Part II, a curve editor control should be added for creating envelopes and other curves. It should take in a trigger and time scale, and output a current value. It should also be able to have a "hold position", which stops the playback cursor at that position while the trigger is high.

This is a tracking issue for the new two-pass compiler being developed in https://github.com/monadgroup/axiom/tree/feature/two-pass-compiler.

Features:

• Designing MIR
• Lowering AST to MIR pass
• MIR passes for use in the editor
  • Order walking
  • Group extraction
• Code generation
  • Statements
  • Surfaces
  • Nodes
  • Standard library
    • Converters
    • Functions
    • Controls
• Lowering model to MIR
• Runtime
  • JIT
  • New audio backend system
  • Value accessor
• Export
  • Export builder
  • MIR passes
    • Removing dead groups
    • Removing dead nodes
    • Removing dead controls
    • Removing dead sockets
    • Deduplicating surfaces and blocks
    • Flattening groups

Right clicking and creating a node, pressing escape while still in the 'enter name' should cancel the creation.

It would be good to have some more audio backends, such as:

• VST3
• AU
• LV2/LADSPA

Some of these also have some nice features that we could take advantage of, such as VST3's flexible I/O.

Exposed controls in group nodes with the 'show name' attribute checked don't have their names visible in the group node.

Edit: The 'show name' button functions on each individual control being named in the code, and not the node name which is somewhat confusing and counter-intuitive.

The following actions were done which resulted in a crash. So far, these haven't been able to be reproduced.

#1:
A 'Multiply' was loaded onto the editor and it's code changed from
out:num = in:num * mul:num to out:num = in:num * mulone:num * multwo:num
When this code attempted to compile, the program crashed

#2:
An 'Add Two' was dragged into a Group Node which caused the program to pause for a moment with the draggable cursor image still visible before crashing.

Edit:
#3:
Extracting an 'Add Two' output knob from a Group Node, connecting the extracted knob to another knob and then un-exposing the add two output node gives the following error:
"Access violation at address 0402A269 in module 'AxiomVST2.dll'. Read of address 00000008."
Attempting to add a 'Multiply' node then causes a crash.
Trying to reload the plugin may not work on first attempt after this.

As part of Controls Part II it would be nice to have a nicer value form system then what's currently implemented.

Basically, the current system tags each value with a form (eg linear, db, Q, note, freq, etc). A statement like [lin] x can then be used to convert the value in x to the linear form, internally using whatever form is stored in the value currently.

This makes sense in a localized environment, but when things start getting more complicated with interactive controls and connections, its harder to use and kinda error prone.

Part of the reason here is the ambiguity of values:

• There is a control form that represents a value as how it would be displayed on a control (mapping to [0,1] and applying curves). But this means that putting a value into/reading one out of a control requires manual conversion to control.
• There is an ambiguously named linear form, which is simply meant to be a number with no form - converting to/from it always returns the same number.
• The above point also means that, for example, there's no way to convert a dB value into a linear (ie multiply-able value)

Sticky Nodes would provide a good way to place and organise text for ideas or other notes in the plugin

When resizing windows, the mouse has to be in a very very precise location for it to register as 'resizing'. Increasing the space the mouse has to be in to register would be good.

The ability to play notes from within the plugin without needing to click onto the FL Studio instance.

Currently the "Open" and "Save" menu options behave more like importing/exporting, since the newly opened project isn't linked to the file. This is because linking to the file often doesn't make sense in a DAW context, since there's just an "intrinsic project" always open - however this can lead to data loss if the user opens a file, modifies it, and expects the editor to prompt them to save changes, which it doesn't at the moment.

This is a proposal to change the open/save behavior in the following way:

• By default, the open project is not linked to any file - in DAW plugins this behaves as it does currently, in the standalone editor the user gets a save confirmation dialog before exiting.
• When opening a file, the project is linked to that file. After being linked, the user is shown a save confirmation in both DAW plugins and standalone editor. Ctrl+S also saves directly to the file.
• DAW plugins store the (optional) linked file alongside project data. The project is linked to this when the DAW plugin data is restored, if the file can be found on the users disk.
• In DAW plugins, there is some way to "unlink" a project file, possibly a menu option. This allows the user to effectively 'import' the project without having the save confirmation dialog (for a more natural DAW experience).
• A "New" menu option to create a blank project should be added - this project would not be linked to any file by default.

Need something really cool for tomorrow.

Hovering over controls at the moment displays the values of each control, but when they are moving, the values are always displayed. When you hover over a constant-displaying-value control, it should revert and show the name of said control.

Currently audio configuration ordering is non-deterministic, which makes things like automation difficult for backends. Audio configuration should be provided in the order the inputs and outputs were created.

The only way to bring the main view back if it's closed is to reopen the project.

Hi, I wanted to try it out, but this happened when I tried using CMake to generate a Makefile:

CMake Error at CMakeLists.txt:32 (add_executable):
  Cannot find source file:

    src/widgets/node/NodeItem.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

This file doesn't seem to exist in the repo. Forgot to git add it? (Happens with me, too.)

FYI, I'm on Linux-libre-hardened 4.13.13 x86_64, but that shouldn't matter.

I've tried your tool for a bit but I found myself struggling to dissociate some elements from each other and made selection harder. I think the UI would greatly benefit from more contrast between different elements and/or windows.
Another solution to this would be to add a color customization option but it'll probably need a lot of work.
Appart from that: it's very cool <3

As part of Controls Part II a new label control should be created. This control should display as a label onscreen, with its name followed by the value formatted based on its form.

We can use Travis.CI for Linux and Mac, and Appveyor for Windows. This allows us to easily provide reproducible releases on all operating systems, which I would like to have before we start distributing binaries.

In the future this might be useful for tests too.

Currently, trying to save an open project will always prompt 'Save As' with no quick save. A 'Save' button in addition to 'Save As' would be beneficial (also updating the hotkey Ctrl + S to quick save).

As part of Controls Part II, a new oscilloscope control should be added. This is useful for "debugging" sounds and other values over time.

The oscilloscope should allow scaling in and out for different ranges, and optionally an X/Y mode.

The module library should be global, accessible from any open project. This probably also means a file watcher system is necessary, so other open instances of Axiom can reload their module libraries when one is changed.

The sliders that allow you to scroll horizontally and vertically through the code of a node seem to have a minimum size to work properly because they don't always work and appear to have greater chances of not behaving the smaller they are.

Using a group node to make a basic circle will produce a circle, but only one regardless of how many notes are being played at once.

If you accidentally make a module tag, it's stuck there forever - even when there's nothing in it. A 'right click/remove tag' would be good, or even a simple auto-delete tags with no modules.

Not entirely sure what is happening here, but the output of the multiply node is starting at 0, yet only begins halfway on the knob as if its values was 0.5. The previous nodes were
Sawtooth Gen -> Add Two (with +1 value) ->Multiply (with 0.5 value).

Using the == in nodes causes a crash on compile.

Setting the value of the input frequency to anything beyond 8 causes the oscillator to output a fixed NaN that won't change, even if the input frequency is returned to 0.

I've tried to generate the projects from CMake but it gave me an error that stated it could not find "Qt5Widgets" package while I use the exact version you mentionned in the README.md.
Any idea how to fix that permanently?

Code the syntax highlighter for Maxim.

Currently the internal structure of undo/redo is exposed through names like Delete Object and Composite. It would be good to have proper naming.

Scaling the minimum and maximum values for controls would be very useful and save constantly having to manually either set the value or add/multiply the end result.

Copying the contents (nodes) from one group node and pasting them into another group node has the following issues:

• Attempting to Check/Uncheck 'Show Name' or 'Expose Node' doesn't change anything
• If there were exposed nodes from the previous group node, they don't appear when pasted into another

The compiler update resulted in a few project format changes that need migrations in place:

• NumValues no longer have an active property, so this should be ignored in older projects.
• History action for setting code has changed, previously it was a CompositeAction containing a SetCodeAction and several control creation/deletion actions - now it is a SetCodeAction which contains those control creation/deletion actions inside.

#35 would be useful to aid history migrations in the future, too.

The following modules cause a crash if loaded:

• Active
• Set Active

There is a non-deterministic crash when putting group nodes inside other group nodes. This seems to be caused by the surfaces not being sorted in dependency order correctly in the runtime.

Allow searching based on node name, and highlighting/moving to nodes that match the search.

Note off events seem to pass through as note on events, which causes a connected voice manager to keep trying to assign voices.

When a new module is created, it should automatically be alphabetised in its associated tag.

It would be intuitive for the size of nodes to be dragged from the 'code box' at the bottom as well as the controls box.

As part of Controls Part II, a new dB meter control should be added, that displays a horizontal or vertical meter with a value.

It might be possible to integrate this with the slider redesign in #3, so sliders can both be used as input and as a dB meter.

Whenever the name of a control is tweaked, its form will always return to the default knob regardless of what it was previously (slider, button, etc). Having a control that remembers its form and only changes when set by the user would be good.

Taking a MIDI gate output to a exposed button on a group node that is then multiplied by the group node's output (volume 0 or 1) always outputs 0.

The user should be able to lock nodes, meaning the controls can't be moved or resized and the node can't be resized. This would also prevent opening the code panel or sub-surface in the case of custom and group nodes.

This is useful for when the user decides a node is "finished", and also for modules (maybe they should auto-lock all nodes in them?)

This is a working issue to track history implementation progress. Below are the history actions that need to be implemented:

• Project settings (not implemented yet)
• Library (not implemented yet)
• Node
  • Adding a node
  • Removing a node
  • Setting name
  • Setting position/size
• Code Editor
  • Changing code (can also add/remove controls)
• Controls
  • Showing/hiding name
  • Setting position/size
  • Changing value
  • Changing display type
  • Exposing
• Wires
  • Adding a wire
  • Removing a wire

Opening the About menu via F1 or the 'Help' button and then closing it causes another about menu to appear.