Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SMF

Pages: [1] 2 3
Compile this with your favourite Arduino IDE, push it to the UNO and get your first RoboVox-Preview while it is hot... ;D

a) you should use a LP-filter on Pin 11 (Audio-Out) to get rid of aliasing above ~8kHz
b) you should use a HP-filter (before or after the LP mentioned under (a)) with about 25Hz to get rid of the DC component
c) you should either
    * attach MIDI via TX/RXs pins (see usual tutorials for this) OR
    * re-programm the AT8U/AT16U with either HIDuino or MIDIklik, so that it behaves as USB-MIDI-interface.

Brief Usage:

Play Midi-Notes C0-C3 (omni-channel) for setting f0. Play higher notes to select phoneme. Velocity changes volume. CCs for controling/altering parameters: See source.

And don't forget to look at the "usage_example.mid" for more details.

Have fun!

PS: If you actually do stuff with it, let me know... ;-)

Is it based on LPC? It sounds different....

No, it is based on "synchronous-windowed-additive-synthesis". This tries to relatively closely model the output of a bandpass-filter when fed with a sawtooth wave (or noise). So it should sound quite similar to the Votrax SC-2 but of course not identical. The Votrax used (depending on the model) either a sawtooth or a pulse-wave (in both cases mixed with noise) to excite three bandpass filters.

LPC indeed does sound completely different. More like a speak'n'spell...

Essentially the synthesis-engine calculates 7 wavetable-oscillators, four of them synchronised to each other and windowed for the voiced sounds and three of them free-running for the unvoiced sounds. All of these oscillators produce a sine-wave. In case of the three oscillators for the unvoiced sounds the oscillators are frequency-modulated with white-noise to simulate the output of a bandpass-filter fed with white-noise.

Usage currently works like this:

  • On the lowest three MIDI octaves you can choose the f0 frequency (pitch of the voice). This will not trigger a phoneme. It just silently sets the frequency.
  • On the octaves above that you can choose to play several phonemes. If played legato these morph into each other. Otherwise they are played separately.
  • Using CCs you can
    • change the position of the formants from super-male to Mickey Mouse
    • change the noisiness of the voice
    • the morphing-time, tremolo,...
    • ...



this is not directly related to the PreenFM in any way, so please bear with me for this off-topic post... But I think it could be interesting for the one or the other here. I always wanted a RoboVox (who doesn't?). But getting the chips is getting more and more difficult and I didn't want to rip it off one of my extension-cards. So, I tried to emulate the thing on a microcontroller (UNO R3 with AT16U for USB). I am quite pleased with the result:

I am currently in the process of smoothing out some rough edges in the FW. After that I would be pleased to share it.


preenfm2 and preenfm3 / Re: The Preenano-Accident...
« on: January 01, 2021, 09:10:04 PM »
A little track I made using some samples for my phone-box and some patches from the bank:

Quote from: Xavier
Thanks a lot for taking the time to write that down. :)
That's interesting.

I really think this is quite bad for the device. But Midi was created so long ago ;)
Or maybe it was not designed to work in real time (while playing sound).

It was... (designed to work in realtime)

The intention behind was just, that small (you could see this as some sort of lossy encoding/compression...) differences would not be too annoying. Esp. for something like filter-cutoff/-resonance, volume and panning... Could be a different thing on something like modulation-indices, though...

These values are lp-filtered on most midi-devices anyways to get more smooth transitions.

For example the Pan parameter expect a value between 0 and 200, than it divides by 100 and substract 1, to have a value between [-1.00:1:00].

Which quite easily could be translated into an NRPN following that lossy encoding: The range [-1.00:+1.00] would/could be translated like this:

Code: [Select]
int panMSB = (int)( (panValue+1.00)*16383.0 )/128;
int panLSB = (int)( (panValue+1.00)*16383.0 )&127;

.. of course this would also work with a range of [0:200] for the panning. Just other offsets 'n multipliers would be used. (Hey, what the heck am I telling you... Sorry :o ) If the LSB would be in a miss (for what reason ever) it would still (coarsely) work. If the LSB was delayed by some tens of milliseconds it wouldn't be noticeable that much -- if at all...

Or IM that accepts between 0 and 1600 and divides by 100 to get a [0.00:16.00] value.
Each time after receiving a CC#6, i would have to send a wrong parameter to the audio engine, and will produce some unexpected audio glitch.

What about defining the NRPN-Data-Entry for mod-indices like this (I am assuming a range of 0:1600 this time, which I guess -- have not looked into the code so far -- is the internal (int?) representation of the IM-values):

Code: [Select]
int modIndexMSB = (modIndex*10)/128;
int modIndexLSB = (modIndex*10)&127;

This would deliver a range of 0:125 in the MSB, resulting in a maximum error of 12.8 (for a range of [0:1600] or 0.128 in a range of [0.0:16.0]). Yes, this can (well, "could") be heard as a glitch. But it would be quite small, I think...

("Something"(TM) in my brain -- from having edited a lot of patches with the editor, lately ;D -- is telling me, that the spectral difference might in fact be so small for the above scenario, that I most probably wouldn't notice even if knowing the difference was there...)

In the current implementation that cannot work at all with the preenfm parameters.

You can also use the PC/mac editor to control any parameters. It knows how to talk to the preen hardware  ;)

Anyway, thanks again for this discussion.

I must admit, that I have not at all looked into the code on how the preenfm deals with incoming NRPNs but I guess it would simplify things a little bit if it were changed to a more compliant way of doing things. The audible glitches can be reduced (most probably to the level were they are completely masked when changed during playback) by changing the ranges of the NRPNs. And for the editor this wouldn't be much of a deal, too.

Essentially I do see two scenarios:
  • Changes of values when using the editor
  • Changes of values during playback

The changes I suggest would be:
  • For all values which can be expressed just within 7bit use the MSB and just ignore the LSB.

    Eg. for the voice-count-per-channel: It is most unlikely that we will ever encounter a preenfm being capable of doing 127(128) voice polyphony in a single channel. That would be a whopping 500+ voices polyphony for the device if only considering 4 channels. Same would apply to the velocity parameter.

  • For all parameters which cannot be expressed within 7bit maximise MSB significance and keep fingers crossed

    ...that delayed LSBs will not be audible too much. This is how all major manufacturers deal with it (some even stating that there rarely might be audible glitches in their manuals when changing values during playback)

Yes, this would somewhat break compatibility with the current implementation. But for the first usecase it is like you already said. The editor knows exactly of how to talk to the preenfm. A new version of the editor is required for nearly every new FW due to changes in the feature-set.

For the second case of changing the parameters during playback inside your favourite DAW, it's just a matter of changing the according midi-template to make things work again. And BTW: Is anyone else so insane like me to change these during playback?  :o I somewhat doubt it...  ;D


PS: See this as just what it is, please... a suggestion or personal opinion or so...
PPS: Please, be also forgiving with me on not looking into the code (not wanting to). I am coding for a professional life. I make music for private recreation. I dislike the idea of coding for music... (well,... sometimes,... I... am... not... that... steadfast...  ;D ;D)

"CC #38 is optional"... have at least 2 meanings.

The term "optional" can have a lot meanings. But as the terms "should" and "should not" in RFCs do not have the "usual" ("common sense") meaning, it is with other standards as well. It is not about what a normal human being would think about the meaning of "optional" but what was defined in the technical papers and why.

Is it the device choice to decide if it needs it or not  and write it down in its midi implementation doc? or does the device should be able to accept without CC#38 in any case.

Is it "the devices choice" weather it needs CC#38 or ot?

Clearly: No.

MIDI-standard defines the term "optional" in the regard of control-messages like this: The MIDI-device shall still work without any flaws, but with reduced precision, even if the message for setting the LSB never arrives.

So, "optional" in this context means: It's upon anyone (including, but not exclusively to the playback-routine(!) producing the MIDI-data) to decide, that currently there is "just" not enough time to send it in full lenght and so it's LSB-value is left out to gain some time. All general controler values shall be defined accordingly.
The later doesn't make any sense.

Sorry, but it does. I just have given a meaningful senario for it. The reason for the irritation might be what a "controller" in terms of MIDI-spec really is: It's the value of a physical device like a rotary-encoder, a poti, a switch or a multi-switch. It's clearly not intendet as a general-purpose comms for the device.

How does the device know if a last LSB CC#38 will arrive after a CC#6 ?

It can't "know" and it should neither be dependend of nor wait for it. In terms of software development: Access to MSB and LSB are not atomic. They are thought to be absolutely independent from each other. And yes, this will produce artifacts. This is why it is not meant as a method of precise data-comm with the device.

It has to wait for the following byte ?

No. If the command for setting the MSB arrives, it sets the MSB, leaving the LSB untouched. If the command for setting the LSB arrives it sets the LSB, leaving the MSB untouched. It is not atomic. It can and it will contain garbage in between. It is not suited for precise data-communication with the device. That's what SYSEX is for...

The protocol in pseudo-code (for the sender side) including some errors or weirdo-things and how to deal wih them from the device-side is as follows:

Code: [Select]
set( NRPN_REG_MSB, 10 ); // set the MSB of the register-address. Block access to data-entry.
set( NRPN_REG_MSB,  0 ); // set the MSB of the register-address. Block access to data-entry. Overrides previous MSB-set
set( DATA_ENTRY_MSB, 10 ); // plainly ignored...
set( DATA_ENTRY_LSB,  0 ); // ignored as well...
set( NRPN_REG_LSB,  2 ); // set the LSB of the register-address. Release access to data-entry.
set( DATA_ENTRY_LSB, 10 ); // set the LSB to 10 whatever is in MSB... weird ... but OK...
sendOtherDataMaybeNoteOnOffs/(); // not a good idea but allowed
set( DATA_ENTRY_MSB,  0 ); // set MSB to 0, leaving LSB at 10
set( DATA_ENTRY_MSB, 10 ); // OK,... set the MSB again...
set( DATA_ENTRY_MSB,  9 ); // OK,... and again...
set( DATA_ENTRY_MSB,  8 ); // OK,... and again...
sendOtherDataMaybeNoteOnOffs/(); // Perfectly OK to do this
set( DATA_ENTRY_MSB,  7 ); // OK,... set the MSB again...
set( DATA_ENTRY_MSB,  6 ); // OK,... and again...
sendOtherDataMaybeNoteOnOffs/(); // Perfectly OK
set( DATA_ENTRY_LSB,  8 ); // weird ... but still OK...
set( DATA_ENTRY_LSB,  9 ); // even more weird ... but still OK...
set( DATA_ENTRY_LSB, 10 ); // even more, more weird ... but still OK...

What if none arrive ?

Then LSB is untouched. Whatever was in before...

How long to wait before considering it will never arrive ?

There is no passive or active waiting for setting Data-Entry-LSB. Realtime protocols simply do not permit this in different messages. I say it again: Access to MSB and LSB is completely indepentent from each other.

Latency will quick become unacceptable.

As there is no waiting...

If the value is between 0 and 200. Is CC#38 mandatory ?

No. According to MIDI-spec, there is not a single allowed situation, where CC#38 is mandatory.

What if a device has a new version, and this new version accepts value between 0 and 150 although the previous one had a 100 upper limit. Changing the meaning of the Data MSB break all compatibility.

I have not heard that a Montage is compatible to a DX-7 within the NRPN range of settings... Or that a Korg E2S is compatible to an Korg ES.

NRPNs only makes sense if that's the device (the preenfm) in its spec that decide how the DATA (LSB/MSB) must be sent and if CC#38 is used.

No... NRPNs are still "general controllers" in a MIDI-sense. Just like volume, panning and/or filter-cutoff. They may also carry the information "switch is in position Nr 0...127" (an no, 0...16129 is NOT allowed in this case, as you cannot prevent illegal intermediate switch-positions due to non-atomic access to LSB/MSB).

As you can guess, i disagree with the title of this thread

Xavier, it's your synth, so it's your decision. I have found a work-around which is not nice but works for me.

And I owned (and still own) "some" other midi-devices with grossly more serious glitches/flaws/bugs in their MIDI implementation. Most of the time this was done due to the precise and understandable wording in the MIDI spec (which in it's original 1.0 form excluded dealing with any corner-case...) leaving the manufacturers (too) much of room for own creativity. But also, sometimes breaking the standard was done by intention.

As you can guess, for me it is a bug in the PreenFM's firmware, still. I could tell you what I would do about it, but I can't tell what you will do about it -- or IF you will do something about it at all.


PS: Do I understand it correctly, that the PreenFM2 does actively wait for the LSB in this case? If so, what will happen if it never arrives? Maybe because the DAW died and was restarted?

PPS: If I had to fix it: I would use SYSEX for things which must be changed in an atomic way. I would keep using full-scale (MSB+LSB) NRPNs only for parameter-changes where small audible "glitches" are allowed. For that I would upscale the range (say you have a range of [-1; +22.3], maybe?) to the full 14 bits, so "leaving" off the LSB makes it less precise but it would still work...

Well, Midi-Spec is quite clear about this (... well, if read twice or more times... I have a copy and it's NOT a nice read... this is the reason why I initially thought it was a FL Studio bug...).

NRPNs (as controllers with MSB/LSB in general) are defined as something like a 14bit fixed-point number with the LSB containing the fractional part. This is the reason for the statement that the LSB "optionally may be omitted". So MSB=39 and LSB=64 would be a controller value of 39.50 and not 5056. The LSB is optional, because it is just thought to be a fine-tuning-value.

The reason for this is also quite clear: Transmission speed/timing. It's three bytes less, which is a lot on a data-rate of only 31.250 bps...

I unfortunately neither can directly quote nor post the spec (thanks for that, MIDI Association,... *sigh*... but why? it's a stoneage-document... I don't get it...)...


I am pretty sure about this now.

The Preen should not use/require "Data Entry LSB" for NRPN-data-ranges specified as being less or equal to 0...127.

As a work around I can declare the data range in FL Studio to be 128 instead of 16 (why 16? max nr of voices is 8 if I recall correctly?). But this makes the controller-knob behaving quite fiddly. But well, it's a working work around...


I can confirm that this is a bug in FL Studio 20.8 (and most probably before...).

EDIT: OOOoopps... I am not so sure about this any more... I re-read my documentation on this topic and if I understand it correctly, then sending out the LSB is only required for data-ranges bigger than 127. Voice allocation per channel is 0...16 according to the above table and so, it should  be using Data Entry MSB, only. I may be wrong, but this now looks like an midi-implementation-bug in the PreenFM-Firmware...??

The editor send's this (the following PAN command is just shown for reference):

Code: [Select]
0000F7CA   2   4     B0    63    00    1  ---  CC: NRPN MSB     
0000F7CB   2   4     B0    62    02    1  ---  CC: NRPN LSB     
0000F7CC   2   4     B0    06    04    1  ---  CC: Data Entry MSB
0009F4EA   2   4     B0    0A    40    1  ---  CC: PAN           

Whiles the editor sends this:
Code: [Select]
000A8D48   2   4     B0    63    00    1  ---  CC: NRPN MSB     
000A8D49   2   4     B0    62    02    1  ---  CC: NRPN LSB     
000A8D4B   2   4     B0    06    00    1  ---  CC: Data Entry MSB
000A8D4B   2   4     B0    26    02    1  ---  CC: Data Entry LSB

So, FL Studio omits the "Data Entry LSB" and transmits the value as MSB °_O ...

Edit: I checked, that it sends out the LSB for data-ranges bigger than 0...127. So, this does not look like a bug in FL Studio, now.



I d' bet it would be like this... so, if the editor works and can change the parameters, the preen works like expected. Fine. In this case it's a bug in FL Studio, then...

I will (of course) verify this, but I must admit, that this is no-where unexpected. I have seen a lot(!) silly bugs in the midi-interface-plugin of FL Studio, so far...

will keep you informed,

Can someone please confirm, that these NRPNs (Algo, Velocity, NumberOfPolyphonicy, Glide) do actually work like they are supposed to with the current FW for the preenFM2? (Before I file a bug-report to Image Line and these NRPNs just don't work because the preen has a bug there and not FL Studio...)

I am following this list for setting up the CCs/NRPNs for the preenFM2 in FL Studio 20.8:

All NRPNs but the lowest four seem to work... CC for Algo works, NRPN for Algo doesn't...

preenFM2-FW: 2.20


preenfm2 and preenfm3 / Re: The Preenano-Accident...
« on: December 28, 2020, 05:30:23 PM »
hmm,... the final bank didn't get a single download, yet... maybe it's not a so good idea to include it in the image, Xavier?

None the less a small (low quality due to size restrictions) audio-test for some patches of the bank.

All audio except drums: PreenFM2+TC Flashback 2+TC Hall of fame 2
Drums: Synthesized on Korg Electribe Sampler 2 (no samples... yes, this is odd for a sampler...  :) )

Sometimes it's quite handy to be able to translate the modulation-indices of one FM-synth to the other. And sometimes you are just curious why you seem unable to replicate some timbre with a different FM-synth, as well...

The following was fine-tuned by ear and verified using a spectrum-analyzer:

DX-7          PreenFM 2(*)
  50.00no matching value: 0.01 is too much 0.00 is too less
100.00no matching value: 0.01 is too much 0.00 is too less
150.00no matching value: 0.01 is too much 0.00 is too less
250.01no matching value: 0.02 is too much 0.01 is too less
300.03??hmm?? bigger jump than expected..

(*) These values are averages over different octaves. The reason for this is: The PreenFM2 seems to have a (quite strongly) varying modulation-index in between different octaves. To get the same spectrum but shifted upwards by one octave you have to decrease the according MI a little bit (sometimes even relatively drastic and not subtle changes are required to keep the spectrum decently steady...). This is neither noticeable on a real DX7, nor on dexed nor FM8. And it's a little bit unexpected, too. (hhmm,... just thinking... could this eventually be due to the high-pass-filter required in between each of the operators for "real" FM with more than 2-Ops?)

Another interesting finding, when trying to estimate the above table: Looking at the spectra obtained by modulation-indices of 0.25, 0.50, 0.75, 1.00, 2.00, 3.00, 4.00 and 5.00, from an ideal 2-OP FM without the high-pass-filter and comparing this to the spectral output of the PreenFM2, I wonder if the MIs really are the modulation-index or just something quite close? Alternatively the highpass-filter could introduce some IMD here, too. The effect is strange and like this: The wrong partials get canceled out and the wrong partials get amplified (mainly in the low frequency-end), resulting in the inability to do the expected FM-highpass-spectra with really high mod-indices. Hmm,...


preenfm2 and preenfm3 / Re: FM Drum synthesis tips and tricks
« on: December 23, 2020, 10:13:53 PM »

this is a very short summary of what to do to get the "typical" drums (808/909-alikes):

Basedrum: Single OP (just the carrier), sine, in fixed frequency at approximately 60-120Hz (taste), frequency modulated with an envelope. The starting frequency should be chosen approximately 50-200Hz higher. Decay at taste fast to very fast.

Snaredrum: Basically the same as the basedrum. Lowest-frequency around 200-400Hz. Starting-frequency 100-400Hz higher. As a second layer add noise. Either white noise (only one OP on the preenFM) or spectrally shaped noise (Modulator: noise, Carrier: Sine, medium to high modulation-index. Frequency of the noise-carrier (center peak of the noise-spectrum) as you like it.

Hi-Hat: Basically the same setup as for the snare-drum-noise but with a center-frequency of the noise at around 4-10kHz. Fast envelope for a closed, longer decay for an open HiHat.

Clap: LFO-Envelope (three to four distinct "hits"/peaks) in the beginning, moderately fast decaying envelope for the end-section. Single Operator set to white-noise.

I'm not too sure that this explanation is really understandable for someone who has not done that before (all others probably wont need one as creating at least the "typical" drums is straight-forward/dead-easy if you have done it, once -- and the not so typical drum is BTW just experimentation in most of the cases). If you don't understand the short hints from above, please don't be afraid to ask for more details. I will try to explain it in more detail/better, then...


preenfm2 and preenfm3 / Re: The Preenano-Accident...
« on: December 23, 2020, 03:34:58 PM »
OK, folks...

this is how far it can get before Christmas. I most likely will add some more patches to the bank after new-years eve...

BTW: Most of the patches have pitch- and modulation-wheel connected. Tip: use it...  ;)

As already stated before this was all done from scratch using the PreenFM-Editor. No patches of obscure origin used, so no trouble with big Y's (or anyone else's) copyrights. For the license-thing: These patches are intended to get you experimenting. So, feel free to do whatever you want to do with them. Consider your derivative work "yours".

 If you however happen to make music with the unaltered patches, I dare to ask you to kindly mention the preen and the patch used (and were to get it).

all the best and stay healthy!

PS: Xavier, I would consider this bank "delivery-ready" (if you can live with the likely possibility of later editions..."...

PPS: Everyone, tell me how you like Palladium (and maybe the other "stuff"), please...  ;D

Pages: [1] 2 3