Roadmap "Dynamic Updates": any effort going on?

I've brought both the cores and AudioStream library into sync with Teensyduino 1.54, I believe. As ever, any problems, please post on this thread or raise an issue on github.

Cheers

Jonathan
 
Minor updates to bring into sync with current cores and Audio library, fix a compile-time warning about an uninitialised variable (code never seemed to execute, though...), and enable an early call to CrashReport within the AudioStream constructor so crashes occurring during the audio system construction can be caught and displayed.

See features/dynamic-updates, tag v0.1-alpha on both repos. They don't need to be in step, but you must have either both dynamic or both (original) static libraries, you can't mix them.
 
Updated in both cores and Audio to pre-release v0.2-alpha: please use both together!
  • Cores is roughly in sync with Teensyduino 1.55 beta #3
  • Documentation updated in the Audio library
  • Defaults to executing all audio objects, even if they're not apparently connected to an audible output
  • Provides an API to turn off/on execution of unconnected objects, to save CPU time
 
I'm planning to merge this (and 3 other audio library efforts) for 1.56-beta3 or 1.56-beta4 later this month, or perhaps slipping into early November depending on how filesystem stuff goes.

I've not said much on this lately. Just wanted to let you know it's definitely on my radar to become part of Teensyduino 1.56.
 
PaulStoffregen said:
I'm planning to merge this (and 3 other audio library efforts) for 1.56-beta3 or 1.56-beta4 later this month, or perhaps slipping into early November depending on how filesystem stuff goes.

I've not said much on this lately. Just wanted to let you know it's definitely on my radar to become part of Teensyduino 1.56.
Click to expand...

That's very gratifying! I did a quick search and couldn't immediately see which other 3 efforts you might be considering - if you post which those are, then I can try to have a look and see if I can spot any changes they may need to make them dynamic (principally getting the destructor right...).

I'm aware of only a few differences from the existing library, and considerations for users:
  • if you attempt to make multiple connections to an input, it's the first one that succeeds, not the last: this contradicts your documentation, but people shouldn't do it anyway
  • AudioEffectDelayExternal needs a destructor to free up its external memory usage - I don't know enough about how external memory is allocated and freed to make a decent job of that
  • I've "had to" put code in to print a CrashReport on the first AudioStream object constructed, because putting it in setup() is too late if there's a bug in the library. There may be a better way to do this
Cheers

Jonathan
 
Best 3.x as test-bed?

I've been reminded in another thread that I haven't made the relevant changes to the Teensy3 AudioStream code. Testing this will be tricky at the moment as I don't have any hardware to test on, just a Teensy 4.1. Officially the audio library supports 3.0, 3.1, 3.2, 3.5 and 3.6: I've noticed the code also mentions LC, which was the variant @Frank B was concerned about.

Does anyone have an opinion on what variant of Teensy 3.x/LC I should target for development and testing? I don't really want to get one of each (unless donated;)). I'm also not massively interested in stress testing to the limits of CPU and memory usage, as I couldn't guarantee full coverage anyway.

Cheers

Jonathan
 
v0.3-alpha release

New release made, can be found at https://github.com/h4yn0nnym0u5e/Audio/releases/tag/v0.3-alpha.

This fixes some issues with creating and destroying input and output objects; I'm not able to test anything other than stereo I2S right now, so would be grateful for feedback on other hardware. Note that these objects never truly get destroyed, because at the moment I don't understand the hardware well enough to do a complete tear-down of I2S, DMA or anything else, so as to leave them free for re-use. However, they do seem to go properly dormant, and it's a fairly unlikely use case in real life unless there's a lot of hot-plugging of hardware going on!

I've also added an AudioAnalyzeEvent object, with documentation in the updated GUI and an example. This should help some debugging scenarios, and also where you want to synchronise with the audio engine's update loop without burning a lot of CPU. It's based on the EventResponder class.

Cheers

Jonathan
 
"the Audio library needs copying in to mask the original, in the usual manner."

Is this correct:
I use your library files as includes in my project?
For the cores, I overwrite my existing library core files with your core files (while saving copies of old ones)?

Thanks, looking forward to using your dynamic audio objects.
 
Tried using Cores Alpha 2 and the Library Alpha 3. I get following compile error:

Code: 
lib\Audio\src\output_spdif3.cpp: In static member function 'static void AudioOutputSPDIF3::isr()':
lib\Audio\src\output_spdif3.cpp:137:62: error: 'silentBlock' was not declared in this scope
  if (AOI2S_Running != dmaState || !block_left) block_left = &silentBlock;
                                                              ^
lib\Audio\src\output_spdif3.cpp:139:64: error: 'silentBlock' was not declared in this scope
  if (AOI2S_Running != dmaState || !block_right) block_right = &silentBlock;
                                                                ^
lib\Audio\src\output_spdif3.cpp:164:21: error: 'silentBlock' was not declared in this scope
  if (block_left != &silentBlock) {
Compiling .pio\build\teensy41\lib95d\Audio\play_sd_wav.cpp.o
                     ^
lib\Audio\src\output_spdif3.cpp:169:22: error: 'silentBlock' was not declared in this scope
  if (block_right != &silentBlock) {
                      ^
Compiling .pio\build\teensy41\lib95d\Audio\play_serialflash_raw.cpp.o
*** [.pio\build\teensy41\lib95d\Audio\output_spdif3.cpp.o] Error 1

any help to point me in the right direction is appreciated.

Note, I'm not calling play_seriaflash in my code nor spdif3.
 
OK, v0.4-alpha is now tagged on github. I would have done a retrospective v0.3-alpha, but it appears impossible without using the command line. Life's too short, right now... So use that version of cores with Audio v0.3-alpha, and all ought to be well.
 
Indeed life IS too short right now :) Thank you so much for putting out a new release! I will give it a try later on today.
 
murdog said:
And it compiles now! Thank you. I'll be coding up a test project soon enough.
Click to expand...
Excellent news. In case you hadn't spotted it, there's Stuff Going On on this thread which is quite fun. We have interactive audio engine building straight from manicksan's GUI++ working, though lots more needs to be done to make everything robust and capable. Just this minute got MIDI control of a crude 4-voice synth going...
 
h4yn0nnym0u5e said:
Excellent news. In case you hadn't spotted it, there's Stuff Going On on this thread which is quite fun. We have interactive audio engine building straight from manicksan's GUI++ working, though lots more needs to be done to make everything robust and capable. Just this minute got MIDI control of a crude 4-voice synth going...
Click to expand...

I've been reading that as well as attempting to use manicksan's impressive GUI tool. I'm already using his mixer.

What I'm working on now is a groovebox that uses a lot of tactile switches and encoders as well as midi input. I'm not sure if OSC would be helpful to me or something I should be using? I don't have a good grasp of it, it seems like a more advanced midi interface from what I can tell.
 
“Should” is definitely too strong a word! It might be useful, though as yet it’s all a bit fluid. It is like advanced MIDI, but much more flexible, and you can use it internal to your application.

manicksan’s GUI++ is impressive, isn’t it?
 
I've just pushed to the repos with the latest Audio and cores, using the tag v0.5-alpha, and recommend anyone who's trying this out to update. There were some pretty massive problems with deleting objects that I think I've now dealt with. But it's quite possible I haven't.
 
I just updated from alpha v.4 to alpha v.6 and everything compiled and ran without issue. Which is great! (I'm still on teensyduino 1.55 btw).

Thanks again for this library, it's a big help for me.
 
murdog said:
I just updated from alpha v.4 to alpha v.6 and everything compiled and ran without issue. Which is great! (I'm still on teensyduino 1.55 btw).

Thanks again for this library, it's a big help for me.
Click to expand...

Excellent news - glad it's working for you. Hope you can post in the future about what you've done, and why the dynamic library was useful to you.
 
I'm trying to make a groovebox. It has multiple tracks and the tracks can use different synth engines. Example, a 4 operator FM synth, a 6 operator FM synth, a sampler, multiple configs of subtractive synths. The FM synths present a particular problem in that they can have several different algorithms. Your dynamic library allows me to easily create and destroy those different engines and algorithms and assign to different tracks. Before using your library the methods I was attempting to use to swap engines were problematic.
 
Ah yes, I recall a separate conversation about problems with AudioWaveformModulated - must look into that, since the audio modules seem to be getting added to anyway in this library! Sounds very cool. Do you know how close you can get to "classic Yamaha" sounds with the FM synths? I have a few wind synth sounds on a WX11 which might be worth trying to reproduce... not sure how many operators that has.
 
I don't really know how close I can get to a Yamaha sound. I've tried to match some of the classic patches of the DX7 and haven't had success yet. Couple issues I haven't figured out- the envelope parameters on the DX7 are so different than in the audio library, I'm not sure if I'm scaling various amplitude parameters correctly, and there have been a few posts here about the audio library waveform not "getting enough modulation" when viewed on a scope. Seems to me like I'm getting all the modulation I want. And I'm getting good FM sounds, so, I'm happy with that, just haven't been able to match the DX7 patches yet.

I'd never heard of the WX11, it looks fascinating.
 
I've just pushed the repos with the latest Audio and cores, using the tag v0.7-alpha. These are my first try to get Teensy 3.x supported, and haven't had much testing apart from a quick go on a Teensy 3.5.

Teensy LC seems to be a no-go at the moment. Not sure if it'll ever be practical due to small Flash size, but it looks as if there's a lot of cruft getting linked that I didn't expect, so it might squeeze in if I can find out what's causing that.
 
You must log in or register to reply here.
Back
Top