DSP Robotics Support

I'm looking for something,
but my little knowledge in the field make me do the same questions,
which could be a plausible scenario?
Maximum how many voices?
for voice: 1 Filter, 2 LFO, Envelope 2, and so on.
how much latency can have?
$ 6 ... you have a link for purchase info?

Here is a video that shows the benefits of the LPC4300 series:
http://www.youtube.com/watch?v=V9jgYLMHsR8

The NGX LPC4330-Xplorer board looks like a good entry level dev. board for it. Here in Germany it only costs 45€ and has all onboard you need for playing with audio.

At Farnell and Mouser the cheapest controller of the series is the 4310
At Digikey it is a 4330
Price is 6-7 €

thx MyCo
I had found this complete package for development.
exaggerated?

Well, you have to buy several modules, that aren't cheap. Some of them are not available (eg. haven't found the codec board in the shop). If you want to use all of the features you can get the full blown dev. boards from hitex.

tester wrote:"Zoom spectra" combined with FFT resolution change would be good for performance. You don't need high resolution for full view, but you need details when zooming spectral area.

Hello, thanks for your comment. I just added :
- the "F Control" panel allowing Zooming
- the "Lin Pad" for quickly accessing frequently used settings in Lin frequency
- the "Log Pad" for quickly accessing frequently used settings in Log frequency
This way you can zoom any portion in the spectrum. For the sake of simplicity, the FFT length stays independent of the Zoom. You thus need to change the FFT length accordingly.

The frequency axis lines get managed for always displaying round numbers in the 1-2-5-10 sequence, both in Lin and in Log frequency representation.

The "True Segments" and "True Bars" rendering tell you the actual FFT frequency resolution, visually. I found the "True Segments" rendering useful, especially when the phase gets dirty. You get a nice cloud of points telling you precisely what's going on. There is more info in this, than the usual LineDraw rendering, which can be misleading.

Watch the green curve. I just added the computation (by iFFT) and drawing of the estimated impulse response. The "IMP Control" panel allows to set the time axis (kept independent of the FFT length), and allows to set the Y-axis gain. There is an "Auto" setting for the impulse response amplitude scaling. The small horizontal black portion just before the green curve is a kind of "pretrigger" area. This way the very beginning of the signal doesn't get polluted by the left side vertical border and/or axis label. The "pretrigger" percentage is set to 10% of the screen width. The small vertical black portion at the very beginning of the green curve is the value of the signal for t=0. It should be unity for an unity transfer function. For a pure lowpass D.U.T, it should be zero. The more you introduce highpass terms in the in D.U.T. transfer function, the more the black vertical portion grows.

I'm only one month on Flowstone now. Thanks MyCo for helping me in some critical areas. MyCo determinant contributions in this particular project are :
- Efficient IIR filtering on an array, using Green code. I found this truly amazing. It opened my eyes, about Synthmaker/Flowstone capabilities. This is in the LPF Fb Hz section. I took MyCo 1st-order LPF and reworked it for implementing a 2nd-order LPF Butterworth, with a variable -3dB frequency.
- Elegant distributed control using a ring Bus. This is in the Frequency control surfaces : F Control, Lin Pad, Log Pad.
- Efficient Ruby error avoidance fix, bypassing any routine that is supposed to manipulate an array, if that array is still "nil" at execution time. This way Flowstone can still generate random triggers during initialization, without Ruby complaining about "nil" issues. This is in the Ruby Draw section, where we draw the gain, the phase, and the estimated impulse response.

Without MyCo, the user manual, the trogluddite "Trigger Tutorial" and the STEM Example Projects from Admin, I would be still nowhere.

No need to say, I'm positively impressed by Flowstone graphing capabilities, signal processing, and MyCo ability to provide efficient, determinant solutions. Feel free to use and abuse this FFT-based Audio Analyzer. I'm interested in users feedback.

Is there a tutorial explaining what to do for translating such experimental .fsm into a neat .exe that I can install on any PC running Windows, using the line-in audio Cinches as "Ref" and "In" channels? Okay, I know I need to remove the left part of the schematic. Then I'm left with the View (connecting to the audio inputs) and the various control surfaces (TB, FFT, IMP, F, Lin Pad, and Log Pad). I'm very curious to see how this FFT-based Audio Analyzer looks, after converting it to an .exe.

Many thanks, again
Steph

Thanks for the gratitude Steph

I think, you can optimize the performance of your schematic a lot. I don't want to say that it is bad, but there are tricks to get better performance out of green signals. These tricks are not documented from the Devs, but they exist and where reported in S|M Forum (but I can't find the threads right now).

1. Use a lot more "Sample and Hold" primitives. This sounds odd, but adding primitives can lower CPU usage of green signals. The reason for this is the way the trigger system works. Have a look on page 90 of the User manual. Let's say you add 2 arrays, then add a Sample & Hold right after it (it is triggered either from another input, or directly from the output). The S&H Primitive ensures, that backward triggers are blocked. So that not every time you read the output of your array addition, the calculation itself gets retriggered. This works perfectly, but it's hard for me to find a schematic that can demonstrate the benefits of this in a small schematic. But you'll notice the difference when you try it big schematics.

2. Don't put everything that has to be done into the "draw" method of Ruby edits. Instead precalculate the stuff, that stays the same. And in the draw event, just do the painting. Sometimes it is even better to precalculate several new arrays, so that you can put the data directly from an array to screen, without having to do scale adjustments. This isn't an easy task, because you have to assure that your precalculation gets triggered, also when the view changes. You have to imagine, that "draw" is not only executed, when you trigger a redraw primitive... it is also executed, when a window overlaps the screen or when you move the FS window... and those redraws arrive in a very high frequency.

3. This is not a performance optimization, but an optimization for readability: Make more logical groups. Your top schematic of the "FFT-based Audio Analyzer" is very big. It is realy hard to follow every connection without scrolling. You might right now be able to understand what's going on, but let's they you stop your work and return in several months to continue, then you would have a hard time to find your way through it. It's better to keep everything in small modules, and give that module a meaningful title. A good practice could be: try to use at max. 30 modules per sub schematic. When there are more, select a logical group of modules and put them into a new module.

That's all for now. Maybe I can demonstrate you the 1. point somehow... I just need to think about a good way this evening, when I've a little bit more time.

MyCo - quick question about "sample and hold" and arrays (recently I noticed too, that this one is helpful for greens). When building an array - is it better to add only one S&H after array builder prim, or - multiple S&H, one per input node?

I've been following this thread in a 'learn' mode ...

MyCO ... what you mentioned about:

1. Use a lot more "Sample and Hold" primitives.

Any type of examples that you provide would be most appreciated !

My HOPE, is that you could provide some very simple, even extremely basic examples to help illustrate how we can improve are schematics.

I ask this on behalf of those, like me, that are quite new to SM/FS programming. I realize that this project 'thread' is of a very complex program ... heck, I'm struggling just to grasp the data that is being displayed ... let alone the schematic

I remember TROG presented a thread on 'Triggers' ... something I still need more reviewing ... but hopefully you could mix in some 'simple' examples with whatever deep stuff you GURU guys are dealing with.

Also, thanks to everyone for contributing on an open thread ... not understanding even half of it, it is still fascinating to follow.

Thanks again!

MyCo wrote:Use a lot more "Sample and Hold" primitives.

The Trigger Tutorial v3 from trogluddite made me fully aware of this. After reading it, my idea was to create a few primitives, implementing a simple realtime scheduler, kind of do_forever loop in graphical format, kind of graphical flowchart, kind of Grafcet, from where you define the sequencing, and no more back trigger propagation. Basing on this I would like to interleave (pipeline) the processing like only allowing the GDI+ to start drawing the lines, when the FFT just got calculated. Honestly speaking, I think this is mandatory in case you are in competion with other software and platforms, more or less deterministic. There should be the beginning of a "deterministic" library, as huge bonus, containing a few primitives towards such direction. What do you think about such idea?

MyCo wrote:Don't put everything that has to be done into the "draw" method of Ruby edits. Instead precalculate the stuff, that stays the same.

I had the exact same idea. I need to check if one can exploit the v.width and v. height coming out of the MGUI primitive that's hooked on the Ruby Draw Component. If this is the case, those two values can act as Green math coefficients. This way Ruby only needs to deal with precomputed data scaled between zero and v.width, and between zero and v.height. When the app asks for zoom factors applied to X or Y, those zoom factors would materialize in Green code. I had another idea which is to determine if the GDI+ is smart enough, detecting when the lines that you ask to plot, are so close that they merge in the same screen pixel, in which case ideally speaking the GDI+ would omit drawing consecutive lines that nobody could see, and replace them by a grand "area plot". Have you checked this yet?

MyCo wrote:Optimization for readability: Make more logical groups. Your top schematic of the "FFT-based Audio Analyzer" is very big. It is realy hard to follow every connection without scrolling. A good practice could be: try to use at max. 30 modules per sub schematic. When there are more, select a logical group of modules and put them into a new module.

Actually I'm thinking redrawing the whole app, into "trenches" that I can stack, possibly using buses. This way the layout doesn't change, being 2 channels (like today), or being 4 or 66 channels (like tomorrow). Is there a performance penalty using buses? What programming style would you advise, for systems needing to process 20 identical channels, like rendering 20 channels on the screen ? Is it possible to multi-instantiate a "trench", creating N channels by only writing a few lines of code? Meanwhile, I'm willing to keep the schematic as flat as possible, avoiding sub-modules, sub-sub-modules, etc. The optimal trade-off depends on the the screen you are using. I'm developing using a 40 inch 1920x1080 screen, and I am test-running using a 15 inch 1280x800 screen. I think we need screens, as big as possible both in pixels count, and in dimensions. Creating and debugging Flowstone schematics using a 50 inch 4K screen : that should be quite standard quite shortly.

By the way, I just created a dedicated thread about the NGX LPC4330-Xplorer you were referring. Last year I bought a few NGX LPC4330-Xplorer boards for evaluation. The issue is the ARM Cortex-M0 used as coprocessor. Last year you could not find commercially available developments systems and debuggers, easy to install, easy to configure, able to program and debug both cores together. I don't know if the situation is better now. Last year, Paul Beckman from DSP Concepts was relying on a LPC4330 for porting AudioWeaver on the Cortex-M4 platform. The DSP Concepts team managed to use the SGPIOs for outputting four emulated I2S lanes for feeding a 8-channel audio DAC. In their implementation, the SGPIO was generating the MCLK, a setup that I don't like. I prefear the Codec having its local quartz, querying the data from the DSP. There are videos on YouTube showing the DSP Concepts implementation. The LPC4330 board was overkill, taking a lot of real estate and needing lots of components for interfacing the external memories. The NGX LPC4330-Xplorer should suffice for most audio applications. Infineon is now coming with an interesting Cortex-M4 portfolio, the XMC4000 series featuring many serial ports able to emulate multiple I2S lanes. The STM32F4 is also good for audio, albeit limited to two I2S making it unsuitable for multichannel audio.
See the new dedicated thread here http://www.dsprobotics.com/support/viewtopic.php?f=6&t=1547

Let's not forget the good (old?) PIC32. Most people don't know that the newest PIC32MX1 and PIC32MX2 feature two I2S ports, bidirectional. Price : about 3 eur. Now that Infineon introduced their own flexible serial ports supporting I2S, Microchip must follow the trend, and expand the PIC32MX1 and PIC32MX2 with new devices featuring up to six synchronous serial ports, each configurable as bidirectional I2S (with no MCLK generation). For ultra-lowcost applications, we have the just arrived Cortex-M0+ which is a downgraded M4 cost-optimized, featuring no I2S, thus you need to fiddle with the Frame-Sync and anyway you cannot go beyond 16-bit audio. Price around one dollar, in volume. A one or two dollar price difference between a M0+, a PIC32 and a M4 can make a huge cost difference, in million sellers consumer products like speaking toys, speaking appliances, wireless audio and car audio. The next step is a chip costing one dollar, equipped with a stereo DAC and some digital audio networking interface, kind of upgraded S/PDIF conveying data and audio altogether. Kind of ARM-Cortex Symphony or SigmaDSP. The day such chip arrives, that will be the end of an era, the DSP56K era and the DSP56K derived products. It won't take long. Microchip acquired SMSC in May 2012 for 939 million dollars for initiating an application-specific microcontroller strategy, highly cost optimized when volumes are high. Surely an ARM Cortex-M0+ appears to be very cheap as generic microcontroller, however if you can buy for essentially the same price a one-chip performing as good and containing all the required interfaces, the choice is obvious. Now comes the question : those SMSC application-specific microcontrollers, what architecture they base on? MIPS, ARM, or something else?

Thanks again
Steph

tester wrote:MyCo - quick question about "sample and hold" and arrays (recently I noticed too, that this one is helpful for greens). When building an array - is it better to add only one S&H after array builder prim, or - multiple S&H, one per input node?

Most of the time you add it at the output. When you have modules with S&H at the output and connect them in a chain, your input automatically has the S&H from the previous modules output.

RJHollins wrote:

1. Use a lot more "Sample and Hold" primitives.

Any type of examples that you provide would be most appreciated !

That is not as easy to demonstrate. Most of the times you'll notice that your graphic control isn't as responsive as it should be, and then you start investigating. That's where S&H most of the time is the solution.
The problem for this control lacking is most of the time a "multiple triggers coming in from one source" issue. Here is a demonstration and the solution:


As you can see, when you only change the left editbox, the top trigger counter outputs twice or three times as much triggers. Now imagine that you have a schematic where a trigger is sent to redraw your screen with some graphics In this case (without the fix) you would redraw the whole screen two are three times, even when there was only a single change! That's unecessary!

Another issue is very hard to spot. That's basically calculation, that is not triggered by a forward trigger, but instead it's forced from a backward trigger. Here's an example:


All triggers from the inputs from the left are blocked, so there is no calculation going on, when you change them. When you press the button on the right, you'll see that the result output still gets the right value. That's because the button trigger coming into the "result" primitive, forces backward triggers through all previous modules and then they do their calculations. This can be very expensive on CPU when this backward calculation comes from a redraw trigger.

@Steph: I'll come back to your post, soon.