Are graphical programming apps (Synthmaker, Synth Edit, PD, Bidule, etc.) really needed/wanted?

[maki]

Many members of this community like to test demoprograms. It is good for all new developers, it gives you rapid feedback and opportunity to test Genera on different platforms and setups. Share your scripts with us, it will help us to learn DSP programmng in C and we shall test Genera on our machines!

[Tzarls]

Thanks for the offer. As soon as I get to a more polished version I'll definitely ask for some feedback. I hope the time isn't too far, even thought sometimes it gets hard to find time for my projects.

[mkdr]

Do you think they have a significant place in the DSP world?

They are really really really good prototyping tools. You get to do stuff faster than you'd ever dream of with C++. It's the same as Matlab really. You use it to prototype your ideas because it's so much faster and has the included tools to get the job done.

And if they are as good as Synth-Maker/Edit you can even develop fully with them. There's plenty of good examples of totally professional SM/SE plugins.

[maki]

I have been thinking about this concept since yesterday and realized that there is one important factor that can jeopardise your plans and our possibility of using Genera in the future. It could be your wife...If she is as impatient as my wife is, you should just focus on some basic infrastructure that allows other users to develop a whole concept further, like importing code, libraries, what ever it takes to make it as open as possible. Make some clever basic tutorials for us, newbies, so we have something to start with. Do not use your precious time for fancy knob design, colourfull backgrounds, "makeovers" and windy animations. Make Genera robust and spartan because a man never knows when womans patience leaks out... and than comes The Rage...

[whyterabbyt]

Do you think they have a significant place in the DSP world?

They are really really really good prototyping tools. You get to do stuff faster than you'd ever dream of with C++. It's the same as Matlab really. You use it to prototype your ideas because it's so much faster and has the included tools to get the job done.

There's one particularly relevant factor in audio... a significant portion of the end users are pretty much already thinking of audio generation, routing and effects in terms of inputs, cables, processors and outputs anyway. These kinds of environments can make it finer-grained, but the notion that boxes-and-wires is intrinsically an inappropriate model for building these kinds of processes is kinda ignorant in many ways.

[valhallasound]

A few days ago I decided to share some aspects of my app with the people at the "modular synthesis" forum, to check the reactions. Some guys were interested, but some of them actually stated that this kind of apps are a thing of the past, just more of the same and never fulfilling the expectations. What do you think? Do you use that kind of apps? Do you find them useful in any way? Do you think they have a significant place in the DSP world? Are they just toys? Do they just spoil people? Will the world end this year?

Here's the link to the conversation at the other forum, in case you want to check the reactions.

http://www.kvraudio.com/forum/viewtopic.php?t=349354

I've worked on the development of a few lesser-known graphic DSP tools in the past (SynthBuilder, VisualAudio), and kind of hate them now. But that is just me and my own experiences. Pure Data is being ported EVERYWHERE, Reaktor is still very popular, Max/MSP is now integrated into Ableton Live, and there are a ton of SynthEdit plugins out there. My guess is that there is always room for innovation in the graphic DSP space.

As far as the negative posts, you need to look at the sources. This is a general rule of thumb I apply to forums (and I have had my fair share of negative posts aimed at me in the past). Look at the profile of the person criticizing you: What do their other posts look like? Are they consistently negative? Do they have only a few posts, or way too many posts? Do they have a particular agenda they are pushing?

In the case of the criticism you received, a quick look at the profile of the main critic shows that they have 2 posts on KVR, and that their LinkedIn profile indicates that they are developing their own graphic programming language. There is a clear agenda here, and probably some insecurity about other people doing what they do. I would ignore this criticism.

Sean Costello

[Borogove]

In the case of the criticism you received, a quick look at the profile of the main critic shows that they have 2 posts on KVR, and that their LinkedIn profile indicates that they are developing their own graphic programming language. There is a clear agenda here, and probably some insecurity about other people doing what they do. I would ignore this criticism.

Wow, that's really classy of them.

[whyterabbyt]

In the case of the criticism you received, a quick look at the profile of the main critic shows that they have 2 posts on KVR, and that their LinkedIn profile indicates that they are developing their own graphic programming language. There is a clear agenda here, and probably some insecurity about other people doing what they do. I would ignore this criticism.
Sean Costello

Yeah, I did that very thing, and came to the same conclusion. I think the 'I dont know this domain at all, but my solution obviously fits the requirements' was the clue.

I'd also point out that in the visual domain, these kind of tools are actually on the rise, from the shader graphs in applications like Maya, to industry-standard compositors like Nuke, to interactive applications like vvvv.

[kilon]

I am one of those biased people who creates his own visual programming language -> https://github.com/kilon/Ephestos

I think that visual code is the future, the same way we know web is the future. There is however still long way to go before visual coding replaces text coding. For instance I am no fan of drag and drop of visual elements, and I am no fan of nodes and cables either. They may work in very high level, but once you try to make something complicate they become really messy.

I kinda agree there is still alot of practically on how textual code really works, so at least for my project I aim for a hybrid between text code and visual elements. Visual coding is still very immature , but it is moving forward , compared to text coding which is pretty much the same for decades now.

On the subject of modular environments like synthedit and reaktor and synthmaker and all others, I think the very fact they exist and dont go away pretty much reply whether are needed or not.

You should also see the target audiance of those too, they are not VST developers per se, most of them are just regular users. Coding is still a very involved time consuming process when its done on an easy programming language like the one I am using , python, for something as messy as C/C++ it can turn into a nightmare for a begineer and average user.

So yes I think that both sides are needed right now, they both fit their roles well, but you can see far on the horizon that a new age is slowly approaching where it will bring the two world together. How that age will look , is a mystery that we will have to wait to unvail itself.

[Loki Fuego]

I don't know about graphical programming apps, but what I really miss is a some kind of high-level modular audio/midi environment.
I'm not a developer (though if I want I could code something, as I have some experience), but sometimes I come with a crazy idea which I want to try out. But I don't want to spend several days on making something that would allow to try this idea.
For example, I want to take a chord, apply a different pre-programmed pattern (forced to scale) to each note, and then send each pattern to different oscillators with it's own fx chain. I know I could probably do it in SynthEdit or Max/MSP, but it would take a lot of time. But I don't want to waste more than couple of hours on it.
I tried SynthMaker and I was able to make something usable in it, but the idea that you have first to make it, then test it and only then apply it to your music always stop me from getting deeper into it.
Anyway I'm always interested in trying out the new stuff, just to see whether it'll suit my workflow and make my life easier.

[whyterabbyt]

For example, I want to take a chord, apply a different pre-programmed pattern (forced to scale) to each note, and then send each pattern to different oscillators with it's own fx chain. I know I could probably do it in SynthEdit or Max/MSP, but it would take a lot of time. But I don't want to waste more than couple of hours on it.

Something like that wouldn't take that much time once you were familiar with the tool. Its just that you'd need a bit of prior investment in time before you could do so as easily. Im not entirely convinced graphical tools entirely mitigate that, to be honest, you'd still need to understand the 'building blocks' to achieve what you want.

[jonnyG]

Good spot Sean!

As a long time Bidule user I'd like to give another thumbs-up for high level modular tools. At the moment I'm using it to test out some concepts for hardware fx, as well as using it for testing hardware by generating tonebursts, ramps and whatnot and recording + analysing responses. In a more musical vein, I use it for adding modular functionality to Live (it complements Live's rack thing nicely for me and provides a bunch of extra MIDI possibilities too) and I also record with it standalone (most of my stuff doesn't have a key, time signature,or even a tempo...)

Maybe I'm not the typical consumer, but I feel that there are many people who want to create "outside the box", but are daunted by jumping straight into DSP. An intuitive modular application give people the opportunity to try out their "what if?" ideas quickly. The devil is in the details though - are there plenty of high level funtions available, or will the user have to build their own from "primitives"? How easy is it to build a useable GUI for finished creations? Is the cable handling messy with large projects? etc...

From your video the application looks tidy and fast though, so I wish you all the best!

---------------------------------------------

@ Loki Fuego: I suggest that you take a look at the Bidule demo. It's very realtime, in the sense that there's no compiling - you connect modules with "cables" and audition the result as you go. It's PC and Mac and handles audio and MIDI. There are a few small caveats though:

1) As whyterbbyt says, there will be an investment in time - there's always a learning curve. The documentation isn't the best, but there's an active forum and the developers visit most days.

2) It's in beta (and has been for years!). It's very stable for most though and a lot of people on the forum use it live.

3) It doesn't export to a self-contained VST. You can however use your creations as VSTs on any machine that has Bidule installed (Bidule can be used as a VST within a host as well as in standalone mode). Bidule can also be used to host VSTs.

Hope this helps.

[mystran]

I think that visual code is the future, the same way we know web is the future. There is however still long way to go before visual coding replaces text coding. For instance I am no fan of drag and drop of visual elements, and I am no fan of nodes and cables either. They may work in very high level, but once you try to make something complicate they become really messy.

I kinda agree there is still alot of practically on how textual code really works, so at least for my project I aim for a hybrid between text code and visual elements. Visual coding is still very immature , but it is moving forward , compared to text coding which is pretty much the same for decades now.

Now, I might be biased in this matter as well, but I think the future isn't necessarily a matter of visual vs. textual. I think the future in more intelligent tools which allow higher level concepts that either involve sophisticated methods or simply get rid of the mundane details.

As a simple example it would be quite useful to be able to state that a signal should be delayed by a certain amount without having to worry about sampling rates (which could be different for audio and control signals transparently) or interpolation or the buffers necessary or how this all glues together on code level. The value of such an abstraction (whether for more abstract design or easier learning curve) is pretty much the same, whether you draw a box and connect some pins or write something like output=delay(input,time).

I'm not going to argue that a visual layer on top of such a system is necessarily a bad idea (eg I usually use visual editing of schematics in LTSpice rather than writing the resulting netlists directly) but I think the value of such a system (if any) is in the expressive power of the language.

[kilon]

Now, I might be biased in this matter as well, but I think the future isn't necessarily a matter of visual vs. textual. I think the future in more intelligent tools which allow higher level concepts that either involve sophisticated methods or simply get rid of the mundane details.

As a simple example it would be quite useful to be able to state that a signal should be delayed by a certain amount without having to worry about sampling rates (which could be different for audio and control signals transparently) or interpolation or the buffers necessary or how this all glues together on code level. The value of such an abstraction (whether for more abstract design or easier learning curve) is pretty much the same, whether you draw a box and connect some pins or write something like output=delay(input,time).

I'm not going to argue that a visual layer on top of such a system is necessarily a bad idea (eg I usually use visual editing of schematics in LTSpice rather than writing the resulting netlists directly) but I think the value of such a system (if any) is in the expressive power of the language.

Yes that is what I meant too. The whole concept of visual coding is that "a picture is one thousands words" so we as coder community need to sit down and think hard how to express complex ideas to simple terms but without losing the ability of going in and fine tuning the details with ease.

My project is based on the Morphic gui, the irony of Morphic is probably the best effort to visualise code and yet its 40 years old as it was first used as a standard GUI for self programming language which as you may or may not know is the first language to implement Object Orientation. Morphic was ported then to smalltalk around the end of 70s ( the only pure OO language )and then is used currently in modern smalltalk implementations like Squeak and Pharo.

So its not that the answer is not here, the problem is that trends are difficult to move as people tend to grap on popular choices and let go only when there is no other option. When their workflow is really really bad.

Of course there is a valid reason "it pays the bills" , a pro coder is obliged to follow the trend of the market to make a living out of coding.

Another great thing about visual coding is the that it goes hand in hand with the concept of live coding erasing completely the process of compiling or stoping the execution to restart in order to run the new corrected code. Visual code environments like Pharo and Squeak is no suprise that they come with very sophisticated debuggers that can put big programming languages like C/C++ and Java to shame. An error in smalltalk will almost never crash your programm, quite the contrary the debugger pops up with an "how may I help you sir ?" attitude not only showing you the error and the entire backtrace not only offering choice to jump over the faulty code and continue execution like nothing has happened but also allowing you the unthinkable to change the code from inside the debugger and just continue with no need to restard your application.

IF you really look at the feature set of those popula languages like C/C++ ,Java , C# ,VB etc you will see that pretty much any popular programming language of today is nothing more thant a cheap crippled copy of either smalltalk or lisp (smalltalk of course borrows loads of ideas from lisp). And I included my beloved python in this conclusion too.

So the problem is not inovation, or practicallity , or improvement but how you can change the mass following attitude of modern people for whom popular means great, and unpopular means bad, difficult to use, not practical.

[mystran]

Yes that is what I meant too. The whole concept of visual coding is that "a picture is one thousands words" so we as coder community need to sit down and think hard how to express complex ideas to simple terms but without losing the ability of going in and fine tuning the details with ease.

Well, I don't think losing the ability to "go in" is necessarily bad. In fact, I think it's good idea to design a system with a limited number of primitive building blocks and specifically without the ability to "go in" because that way you force yourself to build more complex components out of the building blocks, which is a really good way to validate your design.

[...] then to smalltalk around the end of 70s ( the only pure OO language )[...]

Sorry, but I can't resist: this is not true. There are other modern languages that are just as pure as Smalltalk. For a popular example think Ruby: everything is an object and while you can do things like define global functions, internally even those just become private methods of the "main" object and it's still all objects. Even Javascript is pretty pure, though somewhat different and blurs the line between closures and objects. In fact, if we are allowed to use an isomorphism between closures and objects we can also qualify most functional languages.

How far you want to go is a matter of taste, but even with the strictest definitions there are plenty of pure OO languages. Obviously there are also plenty of languages (like C++ and friends) that just won't qualify no matter what.

Personally though, I mostly find the whole OO thing to be a less-than-desirable substitute for closures. Give me guaranteed tail-call elimination and a good compiler and I don't even need my closures mutable (or maybe for performance I might not want to rely no the compiler to do it, but still).

So the problem is not inovation, or practicallity , or improvement but how you can change the mass following attitude of modern people for whom popular means great, and unpopular means bad, difficult to use, not practical.

I disagree. The mass didn't follow because the improvements and/or practicality wasn't taken far enough. For me personally, it's practicality: I haven't found the time to invest into writing a Scheme compiler that could produce code that I could run in a VST plugin. Maybe I'll do it some day.