Audio System Design Tool import?

Status
Not open for further replies.
Oh, I forgot to mention that the code to import has to be started with
"// GUItool: begin automatically generated code"
and ended with
"// GUItool: end automatically generated code"
 
Just for info (if someone is interested):

I was able to fix some errors and enhance some functionality, so I will list the points here, I'm not ready to commit the files.

- fixed: clear selected nodes, works with several or all selected nodes (reason: two counting variables with the same name "i" where used in two nested loops)
- new: change node names (you can assign names to the nodes, these will be used as IDs if exported or re-imported to CPP (Arduino code)
- fixed: import merges imported nodes to existings ones, skipping nodes with the same name
- fixed: tooltips are now working, extracting the first paragraph of the HTML code
(Paul: TODO question is answered ...:cool: solution in jQuery is easy)
Code:
var firstP = $("<div/>").append(data).children("p").first().html();
- new: nodes definition extracted to JSON file
- new: nodes help pages extracted to single HTML files
- new: form pages extracted to single HTML files
- new: asynchronous loading of JSON, help and form data, data will only be loaded when needed
- style: adapted the size of the palette, labels had been partially hidden

As I did hit the "revert" button in my IDE by mistake, I have to reinject the changes from my local history before I may commit them to Github and open a pull request. But if there's any feedback, I would be happy to know, because I don't want to fork a concurrent tool to Paul's solution, but provide some help in fixing problems and improving the tool.

All the best,
Manfred
 
I'd be happy to merge most of this stuff, if you're willing to send pull requests on github.

Truth is, I've concentrated mostly on the Teensy side. Javascript isn't one of my best languages.... and most of what I did was a pretty horrible hack on Node-Red's code. The combination of minimal effort and lack of experience makes for quite a mess!

I would prefer to keep the GUI simple, without tons of toolbar-like things, but I'm pretty flexible on features to accept & merge.
 
The philosophy of keeping it simple will be followed ... so e.g. because of the splitting of the node definitions you may extend the tool with new nodes changing one and creating two new files. So your concentrations stays focussed on the Teensy functionality. And I'm happy to have access to such a great library together with a neat GUI ... ;)

Pull request will follow ...

- Manfred
 
The async loading breaks offline use. Nice as the separate files are, I really want to keep offline usage as a fully supported feature.
 
Well, I will roll back these functions for now, but after some reading, I'm pretty sure the tricky use of the "<script>" tag with "text/x-red" type will be stop working one day with new browser functionality as well. Ok, there is IBM behind this matter, so perhaps this will stay some time. But the idea to pack HTML code in a <script> tag for later use is highly discussable (but, of course, not your problem ...)

For demonstration purposes I like to prepare a node based minimal server which is installed without any knowledge but solves all problems. I'm afraid the paradigm "using javaScript and jQuery offline without any server" will kick the bucket in not so long time, when you see how strict the security changes became in the last few years. But until then, we will swallow the bitter pill and reinstate the "index.html-<script>-tag-solution"

Edit: what's curious - while I'm not able to load HTML files via $.get() or AJAX, there is no problem to load a JSON file vie $.getJSON() even offline ... Makes no sense in my eyes ...
 
Last edited:
Thanks for working on this. It's a huge improvement! I've updated the website with the latest code.

http://www.pjrc.com/teensy/gui/

The only piece I'm not so thrilled about is having the documentation in 2 places. Previously, each object's documentation was all together in 1 spot within index.html. Now it looks like 2 files have to edited when we add more stuff to the library. Or did I misunderstand something?
 
Thanks for working on this. It's a huge improvement! I've updated the website with the latest code.
...
Previously, each object's documentation was all together in 1 spot within index.html. Now it looks like 2 files have to edited when we add more stuff to the library. Or did I misunderstand something?
No, you don't ... ;-) But ok, I might include the JSON data in another script tag as well, so all the data is together again in the index.html file. But I would like to let the node definitions in one place, because it will be nice to lower the redundancies. So we might have one standard node, and then only the differences are noted. Just a thought ...
 
When adding a new object to the library, it's nice to be able to just copy and paste all the stuff for a similar one and then edit. That's how pretty much everything was added as the library has grown.

But if there's a compelling need to have the stuff in 2 places, I can manage.
 
Just tried the latest import. Wow, it's even able to import without the x,y coordinates in the comments. Everything piles up in 1 spot, but still, very nice!
 
If someone is interested:

to extract the <script> tags in the index.html file of the Audio System Design Tool I wrote some lines in JavaScript to run under node.js (I love it!) which do pretty nice the job: extract.js.

You need node.js installed with "cheerio" and "fs" extension (installation via npm is really a matter of seconds). Just for fun I will write the function vice versa - integrate files in special tags in an html file.
 
Last edited:
I added some new functionality e.g. "arange nodes" with <ctrl>+<o> so imported nodes stacked on one pile would be arranged in a column based way to have a start - it's now easier to arrange the rest manually. Pull requests are opened ...

And concerning #59 we may try to set-up the system as you described - we may change it anyway if it's not appropriate.
 
As it's very silent at the moment around the Audio System Design Tool, I presume it's the lack of time which causes the jam of the pullrequests. Just before Christmas I'm sure many are very busy and have tight schedules. My hope is, that the requests had been remarked and will be revisited sometime, but no need to hurry! But as I added some new functionality and proposed a discusion for a solution of #59, it's obvious that I'm corious and excited the know if its useable. So I will be more patient and will await the things to come ... this is not meant as a complaint or criticism at all!
 
I'll look at this soon.

This week I've been a little distracted by replacing my electronics workbench. Work began on Saturday. A tremendous amount of stuff had to be moved and reinstalled. Custom shelves were built. Much needed cleaning and reorganization occurred along the way. Just this morning the equipment all got set up again.

Arduino is very likely to release a new version this week. Yesterday I spent some time working with their latest code. Everything looks good, but it's pretty urgent to check. When they do release, I'll be pretty consumed for a few days with urgent tasks.
 
So I wish you good luck and good fortune for these challenges ... now I wait for a signal from you to continue with the mentioned themes.
 
Very happy to see this update! I was just looking to see if the import feature ever got implemented and found this post. I plan on making a few new objects for the audio library as well as offering up some modifications I have done in another thread.

A couple questions: would it be possible to add buttons/pots/encoders as well as a scalar to map ranges and other IO objects to allow for rapid coding without the need for type coding in the IDE?
Also, is it possible to create multiple different networks within one program that can be switched between active and inactive states? For example have an FM sine synth path and a wavetable path which the user of the hardware can choose, to allow different sound generation/modification paths to be dynamically selected making best use of the CPU?
 
A couple questions: would it be possible to add buttons/pots/encoders as well as a scalar to map ranges and other IO objects to allow for rapid coding without the need for type coding in the IDE?
I had this in my mind to ... they should have a "setup" and a "loop" part with initializing values, an id/name, perhaps a value range.

Your second suggestion is only a question of the implementation ... I think this might be implemented already. So you may have your to "modules" and encapsulate them into a conditional query.

We must be careful - we don' t have a programming system like Scratch but a wiring and configuration tool - I don't believe this should be changed. Perhaps we might use Scratch for Arduino for the programming part and connect this to the configuration via the Node-RED like GUI.
 
Last edited:
Just wanted to drop a note to say well done, and thank you for all your work. When i get around to reworking my project to the stock SPI flash code and the latest library, this tool will be extremely useful. My wiresheet is so complex I gave up using the design tool as it took too long to recreate each time.

It would be amazing to work in both code and wiresheet and have each update the other. Really amazing. This audio library is becoming the most powerful embedded audio library on the market.
 
Status
Not open for further replies.
Back
Top