Have you tried just fmsynth not fmsynth.openfl?
Just
haxe sound.hxml should build that js
If you use lix it should use the same exact version as me because of
.haxerc though
bc I'm a dummy :P
What's your username on github?
Oohh... Nevermine. I just found this guy's that Really similar to mine and already haxe: https://github.com/konstantint/hxAudio/blob/master/src/hxa/fft/FFT.hx
I might have encountered it before come to think of it
As far as this project, I have intermediate DSP skills, but massive UI component dev, app logic kind of things.
I have been wanting to help create something like this for a while but like in your video, you say C/C++ have a lot already going and is fast.
So I was thinking in the start, why not try and create component/modular type framework in C++ that is low overhead performant and modular.
Then Haxe can interface with that layer and assemble the atoms into molecules and drive those.
It would seem to me that if you could create a small framework of synth, effect, mixer, sequencer components, you could start to benchmark real apps made with it.
Then, as that framework gets more stable, start to mess around with adding DSP like class in Haxe, doing the same thing the low level modular pieces are doing and then optimize or see what is even possible.
I have had massive experience building editor like apps in the past, like a ruled canvas(Fireworks/Illustrator) to desktops. I could see this like Audiotool almost, small successes are better than huge ones, the huge ones never work out right.
Alright, that is my mind dump, my email is teotigraphixllc@gmail.com if you needed that for some reason.
Peace!
Ok cool. I’ll respond in more detail later today but that is a good point about c++. My use case is needing more portability (so for example pure c# can be fed into unity without having to deal with building my own native extensions). Haxe code can also take advantage of some macro-based optimizations. But c++ externs (and externs to c++ bindings) do offer more possibilities in terms of optimization. I’ve also found the hard way that it’s better to add your own c++ layer before making externs instead of making externs for the c++ lib. Even though it works fine I kind of want to change the way the cpp externs already in grig work. Because the code could be a lot more readable that way. Also emscripten makes c++ externs more feasible and I myself have written most audio code in my life in c++. It’s kind of the standard for audio. I’ll brainstorm about ways to take advantage of c or c++ code without sacrificing some of the high level optimizations I had in mind or max portability.
And yeah I agree about small successes. I have an idea for a super simple 2 oscillator synth too. Anyway I’ll write more later.
Cool, I use Unity as well for audio. Caustic is an Android app, I am friends with the dev Rej. https://play.google.com/store/apps/details?id=com.singlecellsoftware.caustic&hl=en_US
Since I was mainly a UI dev and tool dev, I didn't have time to learn DSP like I have other strengths at the mid/high level. So my audio apps on Android use Rej's Caustic COre audio engine, straight C++.
I helped him witha bunch of stuff years ago and made his site, he let me use his audio engine.
So for the most part all audio runs on the C++ layer fully cross platform to Mac/Windows/iOS/Android
this is where this idea is coming from, I built a whole OSC decorator framework around his OSC messages and interface with the core this way, form creating subsynths to starting sequencers and adding effects and automation, all done through OSC commands.
its possible and it proved you can have a portable library DSP engine. He is crazy what he did back in 2011 starting.
Alright, let me know when you do!
Peace