Asio selctor hangs after "asio error"

[chjan]

The built in asio driver drop down selector will hang if the connection to the asio driver is lost (for example, the usb connection to the asio soundcard is physically interrupted). The selector then becomes unresponsive.

Is there a way to reset this so that the driver may be selected again?

Is there a way to code "automatically try to reconnect", that would be even better?

Thanks for any help!

[Spogg]

The short answer is you have to restart FlowStone. I’ve had this with Reaper too so I suspect it’s a Windows issue.

I’m not capable of the long answer

[chjan]

Yes, that is what I do and no big deal, but would be nice with some "irrevocable and brute force audio reset and reactivate". Because this could be a problem with a commercial standalone exe, for those into that.

Regarding Reaper, I use it. Reaper also lacks this.

I have developed SoundPimp.com, and in that I have an audio reset available as a one-click button. It works, and while Windows may impose problem, fueling the need for such a reset, it is no problem doing it. Just a piece of software that close down and restart the audio things.

It is much more annoying in Reaper than in Flowstone or its produced exe apps.

I recognize you as a very helpful participant in this forum for years. Would you know what is going on with further R&D of Flowstone? I imagine this is a very good tool for schools that want to introduce students to the art of easy programming and prototyping. So I am curious why that apparently did not happen, and whether there is a way forward for this product.

The one and only major weakness I have experienced is the CPU consumption of GUI modules if you are not very careful. If that was corrected....

And strongly on the wish list would be a dedicated graph tool to study frequency and phase behaviour with a GUI similar to the BODE diagrams in e.g. REW (Room EQ wisard). There are a number of such homemade tools, from participants here, but none of them deliver a "professional grade" feature set. It should be easy to do and give Flowstone a better opportunity in the market.

Also on the wish list would be a set of modules for doing FIR filters, and this is much more often in use now than a decade ago. The modules produced by participants, some of them brilliant, needs to be systemised and become part of Flowstone core. I mean, was it available, and WITH a proper BODE GRAPH Tool, then Flowstone would indeed be a candidate for all those into FIR and DSP programming (Like FreeDSP, a project one could mingle and collaborate with).

I just mention these things in case the right person should happen to read it

[martinvicanek]

There is a "Clear Audio" prim, does that not help?

The other issues you mentioned about Bode plots and FIR filters are true. Maybe that would be a worthwhile project - given that there is not much visible activity lately.

[chjan]

I did not manage to convince the clearAudio, but maybe I should give it another try.

Regarding BODE diagram, I have lately converted the Sun's old SwingX GUI demo for Java to a generic platform that is to be used for this and that various application. A brilliant piece of software since all the SwingX tricks (elegant animation etcetc) are there and the programmer can concentrate on the app core features.

This process incudes a current development of a BODE plot as seen in the picture, and just now scaling of Y and X axis is being added (See the slider that will do that on Y). On the X axis I plan to create discrete options for displayed frequency range, like SUBWOOFER, WOOFER, MIDRANGE, ALL and perhaps more.

As you might spot, this generic application has a handle for dividing the screen and when it is dragged, the BODE is zoomed vertically. So, there could be frequency in the upper window, phase or legend info in the lower, or similar. Changing window content is a one button click operation in a left menu" window not shown.

Perhaps it would be interesting if I put up a small exe of this generic app when finished, as inspiration to a BODE diagram project.

By the way, when displaying live spektrum, it is a "world wide" problem that the high-frequency range is displayed in excess (and unwanted) detail, while the subwoofer range lacks in granularity, due to the linear vs logarithmic nature of things. It would be interesting to make an algorithm that selected points of measure so that their internal distance on the x axis becomes equal, i.e. increasing the FFT window to the extent possible, and then in the upper region make a subset only selection.

I have tried to discuss non-uniform FTT with its mathematical experts, but in vain. But it should be "not impossible" to manipulate an array running around inside Flowstone. Then FLowstone would stand out of the crowd and become extra interesting.

And finally, since mentioning Java, I tend to use that when functionality matures, while very often using Flowstone for rapid prototyping. However, there is really no reason to go beyond Flowstone if it could start to deliver to known DIY DSP solutions (like freeDSP and similar projects). Read: Some imagined and preprogrammed module in flowstone that e.g. dumps FIR data to the DSP, and I anticipate that this would be simple if one base it on existing software for that feature. Then Flowstone would be a REMARKABLE tool for all those people using such DSP solutions. (I was joining the Aurora kickstarter project, a very good solution).

[chjan]

ON GUI EATING CPU. This notorious problem is given in example in the snapshot. I just developed that wide but not tall GUI to be able to have both that and some mediaplayer on screen simultaneously.

The only dynamic data is a couple of peakmeters, and yet, the CPU cost of that is almost 10% CPU, which I would suggest is currently a major obstacle for developing anything complex in GUI. I suggest it deserves its own thread, and that the original programmers are invited to join a discussion on how this problem could be removed.

The DSP of the shown app is less than 0.3% CPU on this i7 machine, so it IS the GUI grabbing the CPU.

Just a suggestion.

[trogluddite]

There is a "Clear Audio" prim, does that not help?

That only resets the schematic's internal streams, which is useful if e.g. you have nasty numbers in a feedback loop etc. - but if the audio driver itself becomes unresponsive, you have to resort to Spogg's solution. I'm having this problem quite a bit myself lately - a recent Win10 update seems to have really messed up my USB ports!

I imagine this is a very good tool for schools that want to introduce students to the art of easy programming and prototyping. So I am curious why that apparently did not happen

I agree that it could have a lot of potential as a general purpose coding system and a teaching resource. Having worked as a product designer in the UK science education sector and as a school lab-tech, I think there are a few reasons why FS didn't succeed there - requiring a lot of work which DSPr may not have had the resources for...

1) Lack of customer support. Schools and colleges expect teaching resources - you won't succeed in that market without step-by-step examples, student handouts, lesson plans for teachers, etc. customised to the exact curriculum being taught. Teachers also generally won't use forums, nor encourage their students to do so - the resources must be readymade and printable!

2) Parochialism. For big success, you need to reach beyond just the UK. Even breaking into other English-speaking markets isn't easy unless you have the right contacts and local knowledge. Support for languages besides English is non-existent besides a handful of helpful forum members.

3) Very strong competition. Products such as Scratch, Arduino, Lego Mindstorms, etc. are far better resourced than FlowStone, and already have strong brand recognition. Once schools have decided on what kit to use, they will cling to it very, very stubbornly (both to save money on kit, and to avoid changing lesson plans).

4) School-level teaching of coding in most English-speaking countries is abysmal, and is often forced onto teachers with no coding experience (partly explaining the reliance on readymade resources). The last UK politician to push for it admitted publicly that she didn't even know what coding is, but that this was OK because, like the unfortunate teachers who she expected to teach it, she was going to attend the one-day-long teacher-training course (cue much mockery from the software industry, as usual). These policies have been failing ever since I was at school in the 1980's, so schools are understandably reluctant to waste their limited resources on coding in the absence of a curriculum and qualification that will attract large student numbers and will be taken seriously by employers or higher-education.

And a kind of number (5): Graphical coding isn't widely accepted for professional work, which is still almost exclusively done using traditional "literate" languages. Only a minority of FS users write DSP, Assembly, or Ruby, and many struggle with the transition from "graphical" to "literate", suggesting that "graphical" isn't always a good "gateway" to traditional coding. I don't mean to criticise anyone as I'm a great believer in fitting learning and working methods to people's individual talents; but, rightly or wrongly, the industry strongly favours one set of talents over the other, and the idea that systems like FS are not "proper coding" is very stubborn (though wrong, IMHO).

The one and only major weakness I have experienced is the CPU consumption of GUI modules

This has long been my biggest complaint, and from many other people too, as far back as the SynthmMaker days. The primary problem is that no hardware acceleration is used - no matter how good your graphics-card is, all GUI rendering is done by the main CPU (using GDI+, an ancient Windows component). Making FS 64-bit and VST3 compatible has been the main focus of development recently, which is perfectly understandable and necessary, but I sincerely hope that the GUI bottleneck is the next major thing to get some attention - I have abandoned several projects because of it.

[martinvicanek]

This is now quite off topic, anyway a few thoughts:

The (unwanted) high resolution of audio spectra at the high end can be overcome by appropriate smearing. Like here: viewtopic.php?f=2&t=3972&p=22927&hilit=constant+Q#p22927
You could further resample and use much fewer data points and have much faster drawing etc.

Drawing in Flowstone: Often the problem is that way too much drawing and processing is performed because of uncontrolled triggers. You really need to profile a schematic for pain points and then work on those. I have had cases where literally dozens of triggers were drawing the same data - unnecessarily - over and over again.

[chjan]

My "fault" to raise several discussion at once.

@MartinVikanek:
The frequency response cloner is very interesting. How about a phase response cloner too? Because, if you had two complete (Freq and phase; Impulse response) of one very good system, measurement A, and another of another (speaker in my case), measurement B, now you could create a system that attempts to impose filters on B in such a way that its response would be equal to A.

You can do that for e.g. headphones too, i.e on my Focal Elear phones, how would it be if I changed it into Sennheiser model X? Very very interesting question for those studying and searching the perfect headphone.

I am into quadrophonic algoritms these days, and then I need 4 speakers that has identical phase curves. I arranged that by getting a second pair of speakers from Hawaii (a friend there), but I am in Norway, so quite a long distance. (It is the Definitive Technology Incline Desktop speakers that are insanely good given their desktop size, and easy to carry around for demos etc. IOW, I use two pairs of these, and I am even outside in the garden to break loose of room interaction and study the "core" results of the algorithm).

For a larger (highend) system on the lab, I have 2 pairs of speakers that are not phase alike, so I must make a filter to do the above. Since I have REW measurements of both, feeding those into some FS plugin that autocorrects B for A, would be great. I have assumed a two step process: 1. Correct minimum phase errors of B and/or A. 2. FIR manipulate B so that it becomes equal to A. Another option would be to make both completely phase linear. That is my use, but I envision MANY speaker and hifi entusiasts would warmly welcome such a plugin. Announce it in speaker forums, of which there are many, and sell it for 29 dollars. You would make money, (if the BODE plot is getting more in line with the REW example I gave the other day). I am just mentioning this in case you are interested in a business opportunity. Such a plugin would need to be able to read the (near field measurement) impulse response of the systems. Look to Export in REW to see choice of formats. REW is free AND a dominant in the market.

There is another interesting issue: The eternal debate whether a minimum phase system with IIR (or passive ditto) e.g. 4th order filters, is sounding worse than a completely phase linear system? So, add a feature that does that; turn any impulse response into a phase linear system, available on a toggle. Now people around the world can sit down and push that button again and again and the debate would blossom.... (I do not believe smooth phase response is of any relevance, but phase deviations from various speaker drivers, that is another matter).

One more idea: A FS based tool to simulate live the behaviour of a passive filter, including some safety brick wall filters on the tweeter output to protect the tweeter. And where you can define a 1 to N way system of speaker drivers. Most common example is a 3 way system. So, a product that makes it easy for the user to define that, and then test various filter configurations live, AB testing. The thing is, to do this in a passive filter, it is a nightmare of tuning components in the filter. Very efficient to do this in the digital domain, so again, I am doing that, but not with commercial ambitions, only for ourselves on the lab. Which speaker builder would not purchase such a plugin?
And then this pluginn would calculate the values of the various passive filter coefficients (easy!) so that when you have found the balance of the system, you would make that filter and replace the digital domain with the analog domain. Or, for those into fully DSP active speakers system, they would export the result in a way that is in compliance with the widely used DSP solutions, e.g. freeDSP, read: load filter data onto some Analog Devices chip.

To study a speaker builders whereabouts, take a look at VituixCAD, a very well made loudspeaker constructor tool. Also free. I see this as the best alternative and will use it in a forthcoming project. There is a SPL tracer tool there, not unlike your cloner. As a potential user of that product and the imagined plugin described here, I would dream of inter-compliance: I do work in VituixCAD, and I am able to import results into this FS plugin and listen to behaviour and do some tuning in the filter system. Or even, I import REW measurements of the speaker drivers into this FS plugin, and then I grab a (e.g.) 3way template, define crossovers, add some other filters on each driver (shelving etc) and then I start tuning up the crossover live. In interaction, I would probably go into VituixCAD and study power responses and other things. Power response is very (!!!) important so it could be a candidate for this plugin also. You can fuck up the quality of a system by doing things wrong in the crossover regions, in particular in the woofer region. A lot to say, so I just gave the skeleton of an idea here.

[chjan]

@trogluddite. Very interesting read and debate. I just hope the corona virus does not coincidentally will be passing by and happen to read your slogan! ))))

I agree in all you say. FS would need a collaborator that somehow has a foot inside the educational communities and then one would have to make an offer that could not be refused, thus creating a starting point for commercialism.

I think a product like "FS for schools" should aim at the agegroup 15+ and try to make an "almost free" pilot run and see what happens. Sound and robotics are prime candidates for a ready made syllabus.

Regarding the asio error, I think you are incorrect. I have found that if I add the audio driver selector in the MENU of a standalone .exe, then it is not needed to restart. There I can select NONE and then again the driver I want, without a restart. This works always. Therefore, there is something in the audio driver selector (i.e. the embedded version) that has some bug, not FS itself and its way of coping with the outer context.

I am glad that I am not alone with the GUI cpu problem. This WAS one of two main reasons I turned to Java, the other being cross-platform compliance. Perhaps FS team should engage some smart programmer and recreate the GUI mechanism into something more modern. It is a show stopper, thus major. More important than VST3.