This is an age old debate with proponents on both sides. There are plenty of visual Programming languages like Max, Puredata, Kyma and so on. These are all great systems that allow you to prototype sounds quickly. Systems like Max now allow you to include low level dependencies written in C but also high level dependencies in JavaScript which arguably would make the system as powerful as any normal programming language.
Personally, I find visual Programming to be clunky. Admittedly, it's very easy to get something up and running if you don't want to learn code. But, when I'm using a visual Programming language, I find myself wanting to write code to fill in wholes. Unfortunately, I'm not a C or JavaScript programmer so I can't really comment on whether or not these technologies fill the gap that is missing in visual Programming languages. Now, I know that many people will shoot me down for this, but I feel that if there were a platform for writing synthesis in c# with a solid wireup (nodal) UI system like say Reaktor, it would enable c# programmers to pull off some amazing stuff and perhaps even attract other types of programmers to the language.
Unfortunately, out of the box, c# hasn't been compiled down to native code in most circumstances. But these days, .NET native is starting to allow programmers to compile down to native code which in the long run may allow for writing externals for Max in c#. More importantly, when compiled for iOS or macos, c# is always compiled to native code.
So the question is, were there a strongly UI based platform for synthesis, that made it easy to code the modules in a language like c#, wouldn't it make visual Programming redundant?
Visual Programming Vs. Code
-
- KVRist
- Topic Starter
- 350 posts since 9 Aug, 2011
-
- KVRer
- 13 posts since 17 Aug, 2016
Interesting idea... why don't you go make it? 
I agree with you on visual programming being mostly clunky, but I think that's only because I am more comfortable seeing control flow written in code. I never could grok the right-to-left order of signals in Pd.
I don't know much about the performance of C# enough to comment on its suitability for real time DSP, but if that's definitely the technology you want to work on, it would definitely be able to do offline DSP. A good place to start might be writing or extending a C# library for common audio DSP operations.
I think there's a place for this kind of platform. Personally, I'm not satisfied with the current tools for audio DSP and would like to see something more scientific than Max/MSP, but more musical than Matlab/Octave.
I agree with you on visual programming being mostly clunky, but I think that's only because I am more comfortable seeing control flow written in code. I never could grok the right-to-left order of signals in Pd.
I don't know much about the performance of C# enough to comment on its suitability for real time DSP, but if that's definitely the technology you want to work on, it would definitely be able to do offline DSP. A good place to start might be writing or extending a C# library for common audio DSP operations.
I think there's a place for this kind of platform. Personally, I'm not satisfied with the current tools for audio DSP and would like to see something more scientific than Max/MSP, but more musical than Matlab/Octave.
-
- KVRAF
- 7890 posts since 12 Feb, 2006 from Helsinki, Finland
Performance is a non-issue really. It's just that if the audio thread gets blocked by something random (say another thread triggered a garbage collection or something), then you might end up glitching the audio randomly every once in a while and .NET doesn't give you the tools to reliably avoid this.. which means that in "serious" audio code C# is just not a "serious" option.danpprince wrote: I don't know much about the performance of C# enough to comment on its suitability for real time DSP, but if that's definitely the technology you want to work on, it would definitely be able to do offline DSP. A good place to start might be writing or extending a C# library for common audio DSP operations.
But like.. purely in terms of performance it's fine. I wouldn't recommend taking your C# code to a live gig or running it while trying to record someone's performance, but other than the possibility of random glitches making it a "no-go" for "serious" stuff, it would be perfectly fine in terms of performance.
-
- KVRist
- Topic Starter
- 350 posts since 9 Aug, 2011
It's funny how many people think that this is an issue in .NET. I've never experienced this issue but it's only 1 line of code to switch the garbage collector to low latency mode.
People say stuff like "don't use it for a live performance" etc. But that's just basically superstition. In future c# will be used more and more for DSP. If it's not good enough for live performance now, it will be. NET is now open source so you can hack it however you like or compile to native. So there's no fluffing around pretending that it's no good anymore.
People say stuff like "don't use it for a live performance" etc. But that's just basically superstition. In future c# will be used more and more for DSP. If it's not good enough for live performance now, it will be. NET is now open source so you can hack it however you like or compile to native. So there's no fluffing around pretending that it's no good anymore.
-
- KVRian
- 1000 posts since 1 Dec, 2004
Benchmark of the current performance of the C# garbage collector:Syncretia wrote:It's funny how many people think that this is an issue in .NET. I've never experienced this issue but it's only 1 line of code to switch the garbage collector to low latency mode.
People say stuff like "don't use it for a live performance" etc. But that's just basically superstition. In future c# will be used more and more for DSP. If it's not good enough for live performance now, it will be. NET is now open source so you can hack it however you like or compile to native. So there's no fluffing around pretending that it's no good anymore.
http://mattwarren.org/2014/06/18/measur ... collector/
-
- KVRian
- 573 posts since 1 Jan, 2013 from Denmark
Garbage collection mostly goes unnoticed in smaller application - and simple plugins. However, you have to think about scale and scalability. Most plugins are advanced, complex, threaded and huge. Now add hundreds of these to your everyday project. Do you honestly believe hundreds of (most likely different) competing garbage collectors will not intervene in an irregular problematic fashion, when your multithreaded host is already slicing and expecting 80% real-time of all hardware threads for audio rendering?Syncretia wrote:It's funny how many people think that this is an issue in .NET. I've never experienced this issue but it's only 1 line of code to switch the garbage collector to low latency mode.
I don't think the problem will ever be solved before garbage collection methods are rethought. Low-latency GC methods only worsens memory performance and fragmentation, it doesn't solve the problem. Deterministic languages scale linearly - and they're optimized in case of huge heaps as they don't have to walk the heap and regularly page in the whole process memory, which truly is a real performance killer.
Is it... really? I'm sorry to derail your thread a bit, but since you weighed in I couldn't help myself.People say stuff like "don't use it for a live performance" etc. But that's just basically superstition.
I program real-time C# audio on a daily basis, and I can tell you first-hand that garbage collection patterns makes your life miserable. We spend so much time avoiding and optimizing this that it's not even funny.-
- KVRAF
- 4590 posts since 7 Jun, 2012 from Warsaw
The issue with garbage collector is not that it's slow. The issue is that it runs in a separate low-priority thread and against real-time thread it has a chance to never actually fire, thus causing out-of-memory crash.
That's why there was Synthmaker, which included both own code snippets and raw assembly. Seriously it was the best piece of softare I ever saw.Personally, I find visual Programming to be clunky. Admittedly, it's very easy to get something up and running if you don't want to learn code. But, when I'm using a visual Programming language, I find myself wanting to write code to fill in wholes.
Blog ------------- YouTube channel
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
-
- KVRian
- 868 posts since 2 Jan, 2013
Actually this is the direction Axoloti wants to go....
whilst currently the software (UI) targets the axoloti hardware, the software side could target other platforms including hardware or software (e.g. VST). ... and because its open source, this is available free to everyone.
I like Axoloti's approach, basically you have visual programming for patching, but then you can create you own objects in C/C++ using the 'object editor', basically this allows you to at the various inlets/outlets/parmeters, and then exposes various calls (e.g. dsp/midi/init) in which you insert the C code. and because its been built to target the STM32F429 it builds efficient code.
(of course the other advantage of the patching environment is you get a ton of musical objects to start, so your custom objects are not the basics, but more interesting stuff.... and of course, you can use the object editor to view any of the library objects)
so for me the answer is visual better than code or not, id say both have an advantage, a patching environment gives you a framework, is great for high level connections handling generic things (like polyphony) ... but code is better for more complicated stuff.
in Axoloti, I routinely chuck together custom objects, just because it might need 20 visual blocks to do ... so its not complex, but just more 'space efficient'
whilst currently the software (UI) targets the axoloti hardware, the software side could target other platforms including hardware or software (e.g. VST). ... and because its open source, this is available free to everyone.
I like Axoloti's approach, basically you have visual programming for patching, but then you can create you own objects in C/C++ using the 'object editor', basically this allows you to at the various inlets/outlets/parmeters, and then exposes various calls (e.g. dsp/midi/init) in which you insert the C code. and because its been built to target the STM32F429 it builds efficient code.
(of course the other advantage of the patching environment is you get a ton of musical objects to start, so your custom objects are not the basics, but more interesting stuff.... and of course, you can use the object editor to view any of the library objects)
so for me the answer is visual better than code or not, id say both have an advantage, a patching environment gives you a framework, is great for high level connections handling generic things (like polyphony) ... but code is better for more complicated stuff.
in Axoloti, I routinely chuck together custom objects, just because it might need 20 visual blocks to do ... so its not complex, but just more 'space efficient'
