tester wrote:Yes, but placing S&H on all inputs (separate trigger sends values to array builder) would not stop refreshing array dozens of times in uncontrolled way? I mean - in array builder, the array is set when output is connected to something else, or is refreshed each time, when somethig comes to any input?
A trigger passed into the array builder (no matter where) leads to a trigger on the output. So if you know, that there'll be value changes on several array builder inputs at the same time, the best solution is to add an update trigger input, that is triggered explicitly. This trigger has to do a S&H on the output of the array builder.
steph_tsf wrote: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.
This is kind of overkill. You can't avoid all backward triggers, unless you put sample&holds after each other primitive. This would propably lead into other timing problems. The easiest thing to do is building modules and examin what happens when a trigger comes in. When there are multiple triggers coming out at the same time, you should start thinking about, how to avoid that. Sometimes it is better to include explicit update trigger inputs, so no matter how much triggers come in, only the update trigger starts processing and updates the outputs.
steph_tsf wrote: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.
You have nearly no influence, when GDI+ draws. You can request redraws with the "redraw" primitives or the "redraw" method in Ruby, but this is just a request. FS & Windows decide when they do the requested redraw and in the meantime, maybe there is another change on your drawing data. Also there'll be a lot of other redraws, on which you don't have influence, eg. overlapping windows, or redraws on other GUI module overlapping or nearby your module. It's easier to prepare all the data you need when a value changes, and in the draw method just paint it on screen.
steph_tsf wrote: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?
Well, I haven't seen any other FS-Like software that is so powerfull in GUI Design as FlowStone itself. When you know the rules, you can achieve anything. Just take a look at this:
http://www.synthmaker.co.uk/forum/viewt ... 210#p73485(you have to enable an audio output in the schematic)
I don't know what you mean with "deterministic" library. Most of the time you need custom solutions for GUI Elements.
steph_tsf wrote: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.
That's not necessary, you can request the size of the view inside Ruby, with the "getViewSize" method, you can see it in action in the knobs from the toolbox. You can also react on module resize events by implementing "def viewSize(x,y,w,h)". There are those comment boxes with arrows in the "example.fsm" that comes with FS, they demonstrate the viewSize method.
steph_tsf wrote: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?
Not really, because you have to implement code to do that, and this can be overkill because GDI isn't very slow in drawing lines. But you can optimize the array that is being drawn, to only contain 2*Width_of_view*Pixels_Per_Grid Items. So there won't be much overpainting on the same pixels.
steph_tsf wrote:Actually I'm thinking redrawing the whole app, into "trenches" that I can stack, possibly using buses.
Buses can be very handy, but I try to avoid them, because you can't see directly what elements are in the bus. It doesn't increase readability.
steph_tsf wrote: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?
Buses have nearly no penalties, it is just connection grouping. The triggers on each connection through a bus has to run through to additional primitives (that actually don't do much), that's all. For the multichannel stuff I would use drawing loops and any data would be store in an array. This can be done with "draw loop" primitive or just with Ruby.
steph_tsf wrote: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.
I'm using a 2x 27" Monitor setup, but I don't like big schematics. I keep everything very modular and synchronize as much as possible to ease future changes.
steph_tsf wrote: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've posted in the thread already. I've checked for IDEs, nearly all of them support the LPC4300. AFAIK it's just like having a M0 and another M4. I would try to use LPCXpresso, the free version has a relativly high code size limit.
steph_tsf wrote: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.
They basically used the demo setup from the example repository:
http://www.lpcware.com/content/project/ ... rted-guideI don't know how accurate the audio clock in an LPC is (it has a dedicated one), but the error rate on an STM32F4 isn't that bad. There is an Excel sheet from ST, where you can calculate that.
On my FPGA board I used a crystal for the codec, but it was connected to the FPGA and then passed through it to the Codec. But on an FPGA this is just as easy as assigning an input to an output.
BTW: When you require many codecs, learn FPGA. With a spartan6 you could drive hundreds of codecs at the same time.
steph_tsf wrote:Let's not forget the good (old?) PIC32. Most people don't know that the newest PIC32MX1 and PIC32MX2 feature two I2S ports, bidirectional.
I don't like PICs at all. You only have 2 IDEs to choose from and none of them has a free version with acceptable code limits. I prefere Atmel, the chips are a little bit more expensive, but the IDE has no limits and is free for all AVR8,AVR32 and even ARM.
It would seem that optimizing AFTER the fact could make a mess.
I think I've found the problem, I've posted it in the knob thread.