jackdotjs / node-studio

Node-based music production tool, built with Tauri.

// click here to go to my website!
window.location.replace(`https://jackdotjs.github.io/`)

node-studio's Issues

convert to typescript

this is one of my last remaining projects that uses plain JS/Node.JS, and I think this one in particular would absolutely benefit from the things TS has to offer.

the only thing im worried about is this: how this will work with the whole browser context stuff? will modules still work as intended? how can we set it up so the browser scripts get compiled to mjs, while all the node scripts get compiled to regular js?

or do we even need to worry about that at all?? idk

@akii0008 i would especially like your feedback on this

VST plugin/instrument support

fix text/number inputs not unfocusing when pressing enter or esc

Midi support!

I have a few midi controllers, i could look into at least the detection and piano playing part if you wanted.

auto-save

mostly self-explanatory

should have an option to set the auto-save interval, location, number of files, etc

Ways to pass data from Webview to Tauri and back

There are a couple of different ways to do this.

One of these is Tauri's built-in implementation with events & serde_json:

• https://stackoverflow.com/a/77895438
• https://docs.rs/serde_json/latest/serde_json/

Another option is an HTTP API on the Rust end

• https://github.com/seanmonstar/warp

A third option (which I am personally in favor of) is a websocket server on the Rust end:

• https://docs.rs/warp/latest/warp/filters/ws/index.html
• Maybe utilizing protobuf to minimize the amount of possibly weirdly structured JSON, especially when passing VST data back and forth.
  • google (makers of protobuf) does not have an official protobuf implementation for rust, however the guys over at tokio have one: https://github.com/tokio-rs/prost

Memoize the waveform and spectrum graphs

https://docs.solidjs.com/concepts/derived-values/memos

multi-window support

something that may become an issue is having multiple instances of the app open at once. at first glance there doesn't seem to be anything wrong with this, but there's one glaring issue at hand: file system calls.

imagine this scenario: a user has two instances of the app open at once, maybe to edit two projects simultaneously for whatever reason. what happens when that user edits the app settings in one of those instances? simple, the other instance will now have an outdated version of the user configuration.

at this point we have at least three options:

1. allow each window to use their own versions of the config and simply allow each one to write them to the disk as they're closed like normal. this means whichever instance is closed last will be the one with the final config used for future instances from that point forward.
2. have each instance watch the config file after launching, and simply load any file changes as soon as they're written. im not sure how well node.js can handle multiple instances potentially attempting to read a single file all at once. keep in mind there could be more than 2 instances, so i think a conflict would be possible. would the read requests jusy be queued? then again i'd assume this is more up to the OS. how would this be handled?
3. use some kind of IPC system to update all instances without having to interact with the file system at all. this could get uncomfortably complicated fast, and may even be massive overkill for this particular use case, but it is an option lol

would love feedback on this

Event Sequencer/Timeline

dropdown menus

needed for the menu bar items (file, edit, view, etc)

this may borrow a bunch of code from the context menu script

Memory usage indicator

module script types do not need to listen to DOMContentLoaded

node-studio/assets/scripts/core.mjs

Line 3 in 87b7870

document.addEventListener(`DOMContentLoaded`, () => {

this is unnecessary here.

fix snapshot builds for tauri port

Export options

In order of importance:

• MP3
• AAC
• OGG
• FLAC
• MIDI
• WAV
• PCM

panel management tasks

• panel resizing control
• percentage-based panel scaling for consistent sizing across any window size
• context menu for panel dividers (to allow splitting or joining panel areas)
• panel tabs and menu buttons
  • menus allows user to switch panel type or remove it altogether. could also provides area splitting/joining controls
  • tabs allows user to keep multiple panel types in the same area. also shows the name/type of panel
• synchronized script interactions for multiple panels of the same type
• json data for saving and loading layouts
  • could also be used for multiple layouts in the same project, similar to blender

Discord Rich Presence support

idk i suggested it and jack told me to like, make an issue to remind so uh

hi jack

drpc pls

all node editor tasks

• allow creation of new node connections
• prevent linking nodes to themselves
• find a way to deal with z-index for both nodes and node connections
• allow creation of new nodes (node menu or context menu)
• allow deletion of existing nodes (delete key or context menu)
• allow renaming of nodes (context menu)
• add further limits on position to prevent nodes from going right up to the edge of the grid
  • should help with minor overflow issues
• prevent nodes from (visually) going more than 50% beyond the bounds of the editor viewport
  • only really needed for UX, allows users to see what node they're dragging around without having to stop scrolling
• add zoom control
  • this one will be difficult. i'm still not entirely sure how we're gonna deal with this one. css transform would be perfect, but they don't affect scroll bar behavior, which is a significant issue. will need more research and experimentation here
• add selection controls

Option to output audio to non-default audio devices

https://github.com/almoghamdani/audify

found through this thread: electron/electron#13771

USB devices

https://lib.rs/crates/rusb

Necessary for midi controllers, special synths, etc.