Wishlist of objects

#59

There is a midi/out/clock object. But there is room for improvement. I don't like the dial to set the tempo. A number box where you can set the BPM would be better.

#60

or, better, yet, perhaps have the out acting like a soft thru and following the midi input??

i dont play keys, i sync everything to my drum machines, so something like that would be useful for folks like me

#61

@janvantomme sorry I wasn't clear. I meant
An object that would allow midi clock to be passed through axoloti. So something that would let you connect midi clock in to midi clock out. I have seen the midi clock out object and don't find it that useful. I'm trying to pass midi clock through axoloti.

#62

I'm using the Kenton MIDI Thru 5 for this. Best way to sync multiple devices to one clock. It's also cheap.
http://www.kentonuk.com/products/items/utilities/m-thru-5.shtml

#63

i just bought this midihub from tindie it has its own midiclock and is pretty cool......

#64

Regarding pvoc and fft for ARM, i found this implementation for MI Clouds (which is build on arm cortex m4 too)
https://github.com/pichenettes/eurorack/tree/master/clouds/dsp/pvoc

Critter and Guitari - Organelle
#65

I'm sure there's a lot of mileage to be had in porting MI code across to Axoloti.

The Braids module is likely to be a goldmine of oscillator types.

Warps has a vocoder inplementation which I'm sure could be ported.

The list goes on...

a|x

#66

porting MI code.
yes it would be possible, but in practice a lot of work ( Ive looked at the MI repo and code base)
probably, 'easier' to take some elements of it, and port it, and do it in an 'axoloti' way.

#67

I'm sure a lot of changes would need to be made, but it would be a good start, in terms of raw DSP code, already optimised for the ARM Cortex M4.

The other issue of course, is that Olivier at MI is pretty good at squeezing the last drop of performance from an MCU. It could be that some of the oscillator types from Braids, for example, wouldn't leave much in the way of processor resources left for anything else, if ported to Axo objects.

I'd still love to see some Braids oscillators, particularly, appearing in Axoloti. If I had the first idea how to start, I'd probably attempt to port the vocal-synthesis ones, and the 'supersaw' unison oscillators, the phase-distortion ones.. actually, just all of them.. :stuck_out_tongue:

a|x

#68

No idea if it's possible, but how about a speech-synth object, based on Flite?

I'd envisage the ability to enter a plain-text string or list of phonemes, and have it step through the phonemes on note-on trigger, with control of pitch in realtime. There would also be some mechanism to reset to the start of the sequence, and perhaps to jump straight to individual phonemes in the list.

Some kind of re-creation of the vocal synth machine from the Monomachine would be great, too, but maybe based on a different synthesis engine, as I never found Monomachine speech/singing very comprehensible.

a|x

#69

Thru boxes are great unless your trying to use axo to poly chain.

#70

a through 0 oscillator would be cool for some different side bands with FM. might be hard to code I have no idea.

#71

i also apply for a midi thru/ merge object

#72

A scope object with 2 inlets would be handy to compare signals.

Unipolar and Bipolar: What does it mean?
#73

Maybe also an option to sync a scope to an oscillators period, so you can view a single waveform cycle.

a|x

#74

+1

yeah, I think the scopes are really useful, I think a bit of time on these could be valuable.
my two 'wishes' I think would be:
- x/y scope
- variable time base

oh, and id really like some bigger (horizontal) ones. often i don't care how much space they take, as they are for debugging. hmmm, perhaps I should consider this more as a new debugging tool for wires :wink:
(@johannes raises an interesting question of introspection... I guess given its native code, we'd potentially have to consider compiling with debugging, and then use debugging hooks... unless 'potential' inspection/watch points, can only be set before you go live)

#76

Emulating an x/y scope is pretty hard to do. If the bitmap is generated in the GUI, it needs a continuous data stream. Displays are polled by the GUI, avoiding a significant performance impact, but no stream continuity.
Generating the bitmap on the target would cause a significant dsp load.
Even low-end digital oscilloscopes based around fpga tech suck in emulating x/y mode.
Even without connecting the dots, every sample is a scattered read+write (unpredictable address).

A two-channel scope 'd be much easier.

Debugging: one approach 'd be importing the linker map file, and perhaps even add some gdb-server functionality. In my development plan this comes after investigating a switch to (lib)Clang (replacing Gcc), to avoid a double effort.

#77

I'd love a PWM Osc with sync input - I've tried cutting/pasting code from both the PWM & Squ Sync oscs (and associated help files) but I'm not getting anywhere with it :frowning:

#78

Generally, Sync and Phase inlets for all the osc types would be cool, I think.

a|x

#79

I would like to have chebyshev waveshaper object. Or maybe some hints or tutorials how one could convert this to axoloti object.

Plus hints for this also.