h4yn0nnym0u5e's latest activity

Just took a look, can't see where you mean?

OK, so I've taken the trouble to answer my own question - FrankB's library does not expose its AudioBuffer class as part of the API, so it's a non-breaking change to rename it. I've done this rename and submitted a PR - he's often / usually quite...

FreqMeasure will give you the revolutions per second. For RPM you need to multiply it by 60. I made my own Electronic Lead Screw controller using a Teensy4.1 and the ILI9341. I use the 1024 PPR quadrature encoder high speed output and simply...

...is also not a proper argument, I admit :) "I don't care" is also not massively helpful. Does your library API require use of the AudioBuffer class, or is it internal-only? Mine exposes it for when the user's code is specifying buffer...

Which has a licence that means it's more likely to get pulled into Teensyduino?

There's a clash between my buffered WAV playback / record library and Frank's compressed audio playback library: c:\Users\Forest Shick\Documents\Arduino\libraries\Arduino-Teensy-Codec-lib-master\audiobuffer.h:42:7: error: redefinition of 'class...

You (or someone...) seem to have grafted together a couple of example sketches and come up with an unholy mess. You'd probably be better off finding a single example which is closer to your aim. Off the top of my head I can see three issues...

Thank you again - I was successful. I have recorded 30 albums so far with no issues. I did add a DELETE button after the 1st 20 albums in case something went wrong with the recording making it easier to rerecord a specific album / side. I am...

Yes, because if (FreqMeasure.available()) { … } Your code does a read() regardless of whether a new value is actually available; that won’t work. Ate you really fitting a 1000ppr encoder, then only using the 1ppr index pulse to calculate...

No offense taken at all. I enjoy getting other perspectives . . . it's an opportunity to see things from a different point of view. No one person can know or think of every way to do something...I'm especially a creature of habit in my software...

Mixers are astonishingly cheap. I did an improved version which optimised channels with zero gain (oddly enough only 1.0 gain was optimised before), and found a 0.0033% improvement per zero-gain channel. So every mixer4 costs a bit over 0.0132%...

Be very wary of using AI for code: time after time it generates nonsense which is just plausible enough to waste a lot of your time * is not a directive, it is an operator - these are two very different things compilers do not correct your code...

Hmmm … I’d expect no change to CPU load, as there’s no obvious need to add any real audio objects; maybe a tiny bit more RAM1 because of the extra classes and their constructors. But the latter could be offset by making your overall code simpler...

Yup, completely unreadable :LOL: It's an ideal candidate for the updated Design Tool that @manicksan did a few years back. Makes it much easier to maintain a hierarchical / modular topology than the vanilla version. It also allows you to create...

It’s not so much the init as the update code, but that was indeed my sticking point. However, any filter is likely to be more resource-hungry, so not really of interest to you. Good luck with the optimisation, I’m fairly sure you’ll find plenty...

That’s certainly a beast! The only thing I can think of to reduce CPU load further is that noise is noise, so could you not get rid of 3/4 of your pink and white noise generators? I did a quick search but am still not sure of your current...

Part of the issue with parallelising the calculations is that the period can be more or less than one block size, so sometimes an update will depend on its own (partial) output! I did think about stealing one of the existing filters’ code to put...

It was quite low CPU, but my changes for fractional indexing (needed both for pitch bend and accurate tuning) and the pitch bend calculations themselves are fairly CPU intensive and far from optimised. I did think about auto-adjusting the...

You don’t need us for that - for once (and I admit it’s a rare occurrence) the compiler is telling you exactly what the issue might be and pretty much what to do about it! Shortening the fixed part of the filename should indeed work, as will...

I’ve used it recently on IDE 1.8.19 under Windows. (I’ve never migrated to 2.x because portable mode isn’t implemented: the issue raised over 5 years ago is locked for further comments with a dev comment that it’s “low priority” - now that’s...

Just to say I've pushed another change to the repo, which improves the tuning. I'm only using AudioAnalyzeNoteFrequency to check, but assuming that's about right the tuning is both better than before, and significantly better than the original...

OK, a little less efficient than doing a full 32-bit transfer, but workable enough! Might as well set 32-bit mode and be done with it. I'll get onto the control code over Easter. It shouldn't be too hard - just a couple of changes to the code...

Less efficient for sure, but it’s a simple non-breaking change to the F32 library, and means a separate TDM_F32 doesn’t (immediately) need to be developed and maintained. If it gets pulled in and I get some encouragement to do so then it’s fairly...

Pulled in, seems to be working fine for me. I've done a bit of work on the F32 library and put in PR #27 which adds conversion of an F32 audio stream to / from two I16 ones containing the MS and LSwords. This can be used to get 24-bit TDM I/O -...

A code update overnight fixes the gain and HPF issues. Use HPF( ) instead of setHPF( )

Yes, I've been using the platypus logo on musical instruments and technology for more than 15 years. I thought I'd bring it across!

That all sounds great - thanks so much for your effort on this, I hope it turns out to be worth it. The multi-TDM code doesn’t directly support larger transfers, though as noted above it could be coerced into doing it using pairs of 16-bit...

The new HPF( ) code has been updated to fix a definition error.

Good news! I’m chuffed myself that you reminded me that I had been working on this, it might have been forgotten for ages otherwise. And I wouldn’t have necessarily thought about the modulation input at all. Hmm … I’m not sure the note stopping...

Yes, repeated noteOn() without noteOff() was definitely causing a nasty audio block leak, which was a bug, and as you say was wedging the whole audio library. All fixed now, anyway ... hope you manage to get the high priority tasks done in a...

OK, the "what" is straightforward ... At noteOn(), a calculation is made as to how many samples are needed for the requested pitch, bent down as far as the current frequencyModulation() has been set. That's rounded up to the next highest block...

Good news. Nice to have some feedback from a Real User, even better when it results in an example to refer back to!

Bug fixed and inputs swapped, new commit pushed - see what you think. I added a "mandolin mode" to my test sketch which just repeats noteOn() calls at a CC-dependent interval; it broke the old code as expected, but the new code seems OK, so I'm...

I'll give HPF() a go at some point - thanks. I don't think there's a way to avoid using 32 (which is available on a back pad of Teensy 4.0). According to the Reference Manual there's only 2 ball-out options, only one of which is brought out on...

I've updated the hardware repo with the full Rev K schematics. The only difference is the added BCLK/LRCLK buffers and removal of the series resistors for DI/DO (as above). I will add the PCBA files after the initial run of boards has been tested.

Not quite right, though my brain is also struggling a bit because one chip’s output is another’s input … and you’ve labelled your signals from the codecs’ POV, whereas I seem to think from Teensy’s! So, Teensy outs need to be 7+32, and ins are...

Hi Mark … glad you’re enjoying it To answer your questions in order quite possibly, the input order was arbitrary anyway. I’ll do that I did mention in post #10, but it’s 22 blocks for C0. It uses enough for the played note plus the currently...

The problem with using any AudioStream-derived object is that it’ll get linked into the update list at construction time, so there’s no way to run it independently apart from something like the bodge I posted in #2, which tramples on the audio...

Yes, the AudioPlaySdWav is only in there because you said you were starting from a WAV file, so it seemed the easiest and most relevant way to put the demo together. If you're starting from an existing buffer of samples, you'd probably replace...

@JayShoe Basically, whatever Paul's licence on his Teensy products is, that's what mine will be. Syncing with an external clock isn't on the cards for Teensy, AFAIK. It's a whole other level of complexity, probably better to use the Teensy to...

For info, here is the “world clock” thread. I think there’s two separate issues here: can TDM be made to work using an external source of MCLK/BCLK/LRCLK, and can the above clocks be regenerated from a studio’s world clock I have no answer for...

Some time ago I wrote an "update grabber" which takes over the audio system so you can graph or log its output in slower than real time. Here's an example I hacked together quickly - not sure if it's along the lines you were thinking, and I...

Input testing: Yellow and green traces are generated on board 0 and board 5, received on inputs on board 0 and board 2, and output on board 0. Far from rigorous, but I'm happy the multi-TDM code is working! Although there are 8 boards...

I'm thinking I could address >16-bit sampling in my playback and recording updates, but have been holding off until I have some idea whether there's any chance of the existing code being pulled into the official Teensyduino distro (1.60 beta has...

Hmmm. I’ve just taken a look at the F32 library, and it appears that minor tweaks to AudioConvert_I16toF32 and AudioConvert_F32toI16, and another to the TLV control object, would allow 24-bit I/O. The converters need two inputs for I16toF32, and...

@mattybrad that’s an awesome project! A hardware version of my soft-patchable synth, but based on Teensy 3.6. I guess the Teensy 4.x one stalled for some reason? Maybe this new board can resurrect the idea… My updated multi-TDM doesn’t support...

Image of WAV file supplied, showing loop points I selected

Slightly surprised that you're surprised by the "audible interruptions", given that your audio file fades in at the start and out at the end, so there's about 0.5s of near-silence if it's looped without setting start and finish points. Here's an...

Note that it must be possible for us to drop your posted code into the Arduino IDE and compile and run it to reproduce your initial result. Short code fragments will not be useful, they often omit relevant information.

Perhaps you could start by posting a short example of code that doesn't work as you'd expect, saying what you expected and what actually happened. At the very least you should also tell us something about the sample data you're trying to play...