If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Audio to Polyphonic MIDI
13 posts
• Page 2 of 2 • 1, 2
Re: Audio to Polyphonic MIDI
crashes and freezes here and there and it's slow as hell.... but works.....
- Attachments
-
- audio to midi.fsm
- (59.96 KiB) Downloaded 1150 times
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: Audio to Polyphonic MIDI
a green delay should be possible at 1ms accuracy with Ruby,
actually-maybe u could shoot for sample accuracy,
maybe I'll try help on this one.
all success
actually-maybe u could shoot for sample accuracy,
maybe I'll try help on this one.
all success
-
nix - Posts: 817
- Joined: Tue Jul 13, 2010 10:51 am
Re: Audio to Polyphonic MIDI
no Nix, not delay in terms of time, but in terms of interaction. what I mean everytime the ruby receives an array it uses also its previous version in calculations. I've managed to do it within green using sample and hold. The schematic works now... as I've expected the precision is pretty lousy and false triggerings are impossible to avoid (with low FFT sizes under 2048 it sounds like random note generator ).
However I'd like to improve the time performance. There's nothing to do with FFT buffering...the input will always be one-FFT-size delayed. Perhaps trogs array to mem can work other way around. Ruby will create memory that can be directly edited within assembly code and ruby component can send "snapshot" of current state of that memory when it receives trigger (of some kind...perhaps an internal timer). Currently you have to send the FFT output sample by sample to a "write memory" primitive, which effectively adds another one-FFT-size delay. With the memory slot directly accessible for both assembly and ruby no buffering will be needed to transfer from one to another at all. - epic anti-latency win!
Also if someone can rewrite the content of the "zero remover" module within my schematic with a single ruby block it might improve both, CPU performance and latency. Theoretically if the module would also create and use above mentioned memory itself, no green would be used at all in the processing chain.
However I'd like to improve the time performance. There's nothing to do with FFT buffering...the input will always be one-FFT-size delayed. Perhaps trogs array to mem can work other way around. Ruby will create memory that can be directly edited within assembly code and ruby component can send "snapshot" of current state of that memory when it receives trigger (of some kind...perhaps an internal timer). Currently you have to send the FFT output sample by sample to a "write memory" primitive, which effectively adds another one-FFT-size delay. With the memory slot directly accessible for both assembly and ruby no buffering will be needed to transfer from one to another at all. - epic anti-latency win!
Also if someone can rewrite the content of the "zero remover" module within my schematic with a single ruby block it might improve both, CPU performance and latency. Theoretically if the module would also create and use above mentioned memory itself, no green would be used at all in the processing chain.
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
13 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: Google [Bot] and 86 guests