Audio System Design Tool import?

Status
Not open for further replies.
I just wrote an import functionality which is able to import the code we use in the Arduino IDE into the Audio System Design Tool. Works fine at first sight - I just added a checkbox to the import dialog so one can paste the code there and it will pe parsed instead of the expected JSON data. Ok, my function just does this: it generates an object with all node settings and sets all ins & outs and then it will be JSONstringified and imported over the localStorage - really no rocket science.

And there is my question: I like to contribute this functionality, should I directly propose the changes in the Github project, or would a fork to my repository be better to test first and adapt afterwards?

While coding, some other questions also came up: isn't it possible to define nodes of "custom" type like knobs, buttons, MIDI-Inputs etc. togehter with just the basic code you need to get started with a Teensy so we may plug some more functionalities together which later must not be written manually in the Arduino IDE?
 
Well, I forked the code on Github and put my changes there, so anyone interested may test the import function. I pulled a request to Pauls master branch - if the function seems useable, it might be merged there.

Edit: added link to repository fork ...
 
Last edited:
@Paul

One question arises when looking through Node-RED and analyzing the Audio System Design Tool: as I see you rewrote some core code of Node-RED so it would behave in the expected manner. But when I look to the possibilities of Node-RED, I believe that you may implement a Audio Design Tool with the Node-RED core as is and just implementing specific nodes as shown in their repositories. Because in this case there could be as possibility to attach this tool directly to the Teensy - an Arduino node already exists.

The only problem I see is the use of node.js if Node-RED runs as a server ...
 
I'm looking at your code now. Or a diff of what's changed. There's nearly 1000 lines altered which appear to be only reformatting white space!

Any chance you could create a copy on github with only the actual changes?
 
Oh, sorry, I'll look into it. That was the PHPStorm IDE being a little "hyperactive" ... ;)
 
As I'm sure this might happen very often and that it's not always helpful to "rechange" a file, Github has some secrets which will help a lot in this special occasion: when browsing the commits/changed files, just add "?w=1" (the text between the quotes) to the end of the URL of the file, and the whitespace diffs will be gone ... This helps a lot more than always be aware not to touch any whitespaces or empty lines ... An explanation may be found here at Github ...

Edit: the file "view.js" has a lot of changes, because I reformatted the code with PHPStorm for better analysing possibilities, so indeed there are a lot of changes with no functional purpose, but with the secret shown above, the number of changes will decrease. The main change in "views.js" are some inserted lines in the function "importNodes" (approximately line 1477 in your last version) which will handle the transformation from CPP code to JSON. As it is not so simple to rollback this commit and as well adding a new version without these whitspace/formatting changes is more confusing, I presume. As the other files have only a reasonable amount of changes, it would be the best, we let the view.js now untouched and I'm aware of the effects, a beautifying reformat will cause when looking for diffs.

Edit: These are the changes in "view.js":
Code:
// line 1477
	function importNodes (newNodesStr, touchImport) {
		// TODO: solve this more elegant as the system expects
		if ($("#node-input-arduino").prop('checked') === true) {newNodesStr = RED.nodes.cppToJSON(newNodesStr);
			createNewIds = false;
			RED.storage.clear();
			localStorage.setItem("audio_library_guitool", newNodesStr);
			RED.storage.load();
			redraw();
			return;
		}

		try {
			var createNewIds = true;

			var result = RED.nodes.import(newNodesStr, createNewIds);
...
.. and a screenshot of the diff (the changes based on removing the /*ESCAPE*/ comment might be ignored):

Screenshot of differences
 
Last edited:
Seems that the use of the Audio System Design Tool is not of very high frequency - the resonance in this thread speaks for itself. No problem anyway, but good to know how to set the priorities. Nevertheless I believe the opportunities with this concept are immense ...
 
I for one am very interested, just have no background with Node-RED. Don't be discouraged from a lack of response from Paul he is working on two major hardware projects that I am aware of, an upgraded teensy with hardware FP support and the new Prop Shield. His time to look at issues that come up on the forum is very limited that's why packaging everything cleanly as possible will result in more response from him.
 
I'm also a frequent user of the design tool. But my filter setups are so simple it doesn't really bother me to redraw the whole signal flow chart every time I change something. :D
 
Yeah, I looked at this days ago, and when it became clear the massive number of non-functional (mostly white space) changes would require doing things very differently than I normally do, I set it aside. Since then, quite a few other urgent things have come up, so I haven't managed to get back to this (yet).
 
No problem at all, but as I read in another thread, someone asked for the same functionality, so I thought there would be some need of this, and I was astonished that perhaps I misjudged the situatiom. I hope no one thinks I'm complaining - who am I to do so? And please be aware I'm not a native English speaker, so it might be that now and then I use expressions which are not always appropriate to the situation they should describe ...

For the moment I see no chance to solve the whitespace problem nicely - with any new version it will re-emerge. Or is there an opportunity to undo a commit in github online? I didn't find any solution in this direction. The only way would be to delete the fork, refork again and then insert the changes without any format changes ...

As I use PHPStorm as my IDE which connects directly to the git repository, I have to be aware not to use the code formatter when analyzing code or editing code I like to commit. Usually I presume the availability of tools showing diffs without the "whitespace only changes" (PHPStorm does it, Eclipse, Kaleidoscope ...) and there is no thougth about unnecessary formst changes. In fact the Github hint with "?w=1" as URL parameter could be helpful to avoid the worst cases. But anyway, Paul, as it is your project/repository, I would like to adapt your code formatting practice.

And as I never would like to seem impatient I'll wait until more steady times emerge and we may discuss the matter with ease.
 
Concerning Pauls lack of time because of big projects I'm aware now - thank you for the information! I'm happy because of the nice answers!

I for one am very interested, just have no background with Node-RED.
I don't believe one need a lot of Node-RED knowledge to use the tool and also to contribute to the functionality.

The tool is a stand alone part of the Node-RED GUI wihout the underlying node.js server part. I presume it's done so because we may use it locally with no server needed. There are pros and contras to use the Node-RED code like this. Pro is: the existing node description in JSON might be used without creating new structures, the GUI is nice and easy to use. Contra: one has to be aware not to change any core parts of the Node-RED code, because in this case updates of Node-RED will be not possible.

On this base there could be a lot of more nodes defined which will provide digital or analog reads defining knobs, switches etc. and from which at least the setup code for inititalization might be generated. With a little phantasy I imagine the complete graphical description of a simple audio application with all Arduino code generated the sketch needs. As the main effort is put in the library itself (big applause here ...) the tool could be the glue to hold all together. And also users could create their audio tools without the need of coding ...

Just some thoughts ... ;)
 
Either way, I will work on merging this... but it would save me a lot of time and trouble if you could create a new fork of the audio lib and commit only your code changes, without many hundreds of other lines altered.
 
How do I run your version to try it out?
Just download the ZIP file provided by the button named "Download ZIP", unpack the file into a folder of your choice and open the folder "gui" inside. The must be a file "index.html" which you may open in a browser of your choice - it then will show the tool's GUI. But this is not yet the new version, because I live in Germany, I will be not be able to create a new version until tomorrow ...
 
Ok, now the new fork is out and changed without any annoying whitespaces and empty lines. Pull request is done, but unfortunately i stumbled over some errors in node handling: I could not edit the name of the nodes I created with the tool, and I could not delete the nodes, if there is more than one node selected. These errors concern the version I forked, so they are not connected to my changes. Either way I'll try to debug the code and find the reason of the misbehaviour - because without the node handling working correctly, the import is just a "hack" using the localStorage of the browser.
 
It's merged. :)

The multiple selected delete and rename bugs have been there all along (well, since I butchered the Node-Red code).
 
On the names, there's a lot of leftover stuff from Node-Red which I never really found and edited. Originally Node-Red auto-generated unique/random strings. I replaced that with the short names with incrementing numbers. I probably broke lots of stuff....
 
Status
Not open for further replies.
Back
Top