DSP Robotics Support

MyCo wrote:Well... that's already there

great!

Exciting to see some progress again!
In a future release I'd love to see:

1. A reliable way of accessing memory from assembly (code optional). In other words: a memin that does not produce random crashes. Or maybe the current memin implementation just needs better documentation?
2. Possibility of writing 16 Byte aligned data to memory (which could then be accessed from assembly, refer to above). Currently there is the (Mono) Float Array to mem prim which can be used together with the (Stereo) Wave Read prim, but that is not the most efficient way.
3. Stream triggered generation of MIDI events (primarily note on/off). Green is not an option because of unpredictable timing. Ruby Frames are not viable because of excessive CPU even if you process only one in 32 samples.

I agree with No. 3

But I don't even understand Nos 1 and 2

But if Martin says it's a good thing then I agree

Cheers

Spogg

I know where 1 and 2 come from

But I am confused from 3
Let's ignore that the midi protocol is its own timing system and is not associated to dsp (Even todays DAWs work with a resolution of 960ppq - FL Studio even only with 96 ppq)

The Ruby Frame description doesn't make sense to me. Processing one each 32 samples? Assuming a sample rate of 44100 Hz that's 1379 midi events per second! Nobody needs that many events? (At bpm 120 that's 1379 midi events within 1 half note)

I personally liked the idea of stream MIDI mainly because I don't yet know any Ruby, and my guess is that there are others who could similarly benefit.

I'm sure Martin will clarify his high CPU point...

Cheers

Spogg

No, I am not trying to generate a thousand notes per second. Not more than a few notes, often less than that. But those should be triggered without jitter. I am happy to accept some (constant!) delay <10ms, but not jitter.

My default control signal processing is at hop(32), which translates to roughly 0.7ms at 44.1k sample rate. That's why I threw in this figure. I was assuming in Ruby you'd have to check constantly wheter there is a trigger event (each 32 samples in each frame), but maybe there is a cleverer way, some sort of push mechanism. Maybe one could also relax that 32, you are right.

Please upgrade the "File Dialog" Primitive to enable one to load more than one file at a time if one wish to do so as well as to select only certain files from a list.

Spogg wrote:Many commercial plugins feature a drag and drop facility for loading say Wav files for drum machines, wave players, wav oscillators and so on.

I think that is possible, the primitive would output the file name of the dropped file(s) I guess. The primitive itself would need a view input that would tell that it reacts only to drops if the drop occurs on its view. I'll put it on the todo list, but it might take longer and I'm not 100% confident that we can get it to work, because I might miss a critical detail

martinvicanek wrote:A reliable way of accessing memory from assembly (code optional). In other words: a memin that does not produce random crashes. Or maybe the current memin implementation just needs better documentation?

That was added in the betas already and should work:
viewtopic.php?f=3&t=3861&p=21277

martinvicanek wrote:Possibility of writing 16 Byte aligned data to memory (which could then be accessed from assembly, refer to above).

There is already a float array input on ASM code primitives. See the link above.

martinvicanek wrote:Stream triggered generation of MIDI events (primarily note on/off).

I'm not certain that this would be even possible in a usable way. We would have to call a FS internal function from ASM. We might be able to do this by remodelling C++ calling conventions in assembler but there is so much stuff that could break when jumping from user code into program code. Also there wouldn't be a "MidiOn..." instruction, it would probably be more like:
fill register x
fill register y
fill register z
call MidiOn
... or something along those lines

tiffy wrote:Please upgrade the "File Dialog" Primitive to enable one to load more than one file at a time if one wish to do so as well as to select only certain files from a list.

Good point. Although this brings up an interesting question: how to output multiple files from the primitive without breaking backward compatibility.
I'll add it on the todo list