operator feedback

[matrix12x]

I was just looking over the DX7 algorithms and noticed that some allowed an operator to have feedback. I was wondering how we could do this on the PreenFM2?

Assuming we had a FEEDBACK parameter, would it be something like:
oscState1.frequency =  freq1 * voiceIm1 + oscState1.mainFrequencyPlusMatrix;
         float car1 = currentTimbre->osc1.getNextSample(&oscState1) * FEEDBACKValue * currentTimbre->mix1 * div2TimesVelocity;

[Xavier]

Feedback is less usefull when the synth offers you several waveform to chose from. Often use in DX7 to create saw or noise.
In adition it is very easy to implement with phase modulation (DX7) but it's more complicated with real FM (preenfm).
With FM, yhe feedback will change the pitch of the operator... You'll need to add a HP filter to get rid of the constant value.

Feedback should be a variable of the Voice class so that it can remember the value and reinject it the next loop iteration.

Xavier

[matrix12x]

Thanks.

In code what is the difference between PM and FM? Are there any good articles on this?

I had thought that an instantaneous change in phase caused an instantaneous change in frequency?

[Xavier]

The second part here is good :
http://www.musicdsp.org/showone.php?id=160
Replace "PM is better that FM" by "PM is different...." 

"(with PM)... cascaded carrier-modulator pairs and feedback modulation are possible."
I added LP filter for cascaeded operators to get rid of the constant frequency value (pitch shifting).
For feedback we should do the same.

Xavier

[matrix12x]

awesome. thanks. That site was great. I found it a while back while looking to code a sample rate/bit rate reducer.

Are there any other good sites or books to read about coding in C for music applications such as the PreenFM2? Are there any differences when coding for an ARM vs the ATMega?

How much ram do we have remaining in the PreenFM2?

Also, to remove the DC offset created by operator feedback, would we subtract the mean from the signal?
Thanks,
John

[6581punk]

Coding on the ATMega is like programming an early home computer from the 1980s.

Coding on the ARM boards is like programming an early smartphone.

That's in terms of resources anyway, execution speed is much quicker. You don't have any OS to worry about in terms of memory.

[pld]

awesome. thanks. That site was great. I found it a while back while looking to code a sample rate/bit rate reducer.

That reminds me, I started a decimator effect but apparently got distracted

Are there any other good sites or books to read about coding in C for music applications such as the PreenFM2?

Other than musicdsp, I think there's a bunch of stuff in the kvr-audio forums, but I've mostly been picking specific parts (oscillator, envelope) and googling my way through the softsynths and VSTs that pop up...

Are there any differences when coding for an ARM vs the ATMega?

You can get pretty far in C/C++ without worrying about the platform, but there are different pitfalls on each (e.g. memory access, FPU or not) if you have performance goals.
E.g. the ARM instructions only work on registers, not directly on memory, so often you have to force the compiler's hand by loading to a temporary variable, processing, and moving back.

How much ram do we have remaining in the PreenFM2?

I think the 64k CCM was pretty full, but I suspect there's still a good chunk of the 112k (?) RAM left. IIRC the code lives in flash.
There shouldn't be any run-time allocations, so there might be a map file or output from the linker that shows usage? Haven't checked...

[Xavier]

At the end of the compilation you get a memory dump.
The following lines are interesting :
                                                                                     
  [ 3] .data                   PROGBITS       20000000 050000 002a8c 00  WA  0   0  8
  [ 4] .jcr                      PROGBITS        20002a8c 052a8c 000004 00  WA  0   0  4
  [ 5] .bss                    NOBITS             20002a90 062a90 0085fc 00  WA  0   0  4
  [ 6] .ccm                   PROGBITS       10000000 058000 0090e8 00  WA  0   0  4
  [ 7] .ccmnoload      NOBITS             100090e8 0610e8 006074 00  WA  0   0  4

10000000 is CCM (64kb)
20000000 is regular mem (112kb)
After the adress, first value is offset the second one is size.
CCM :
We have 0090e8 + 006074 = 61788 bytes out of 65536.
The descending execution stack starts at the top of this memory, so we can consider it's full.

Standard memory:
002a8c + 000004 + 0085fc = 45196.
So yes there's free RAM here for new waveforms 

Are there any other good sites or books to read about coding in C for music applications such as the PreenFM2? Are there any differences when coding for an ARM vs the ATMega?
...
Also, to remove the DC offset created by operator feedback, would we subtract the mean from the signal?

I don't think there's book for coding music applications in C. There is C/C++ on one side and understand how a synth work on the other one.
Then there are lots of information on the web to link both sides.

To remove DC use a simple HP filter.
You can have a look here :
https://github.com/Ixox/preenFM2/blob/master/src/synth/Voice.cpp#L2952
And line 2967 and 2987.
I filter freq4 to remove DC.

Xavier

[matrix12x]

Is that DC filter similar to http://www.musicdsp.org/archive.php?classid=3#135

also, unrelated, but what does "localv0L" and "localv0R" do?

[pld]

Is that DC filter similar to http://www.musicdsp.org/archive.php?classid=3#135

Looks like it, where x(n) = f4x, x(n-1) = f4xm1 etc.

also, unrelated, but what does "localv0L" and "localv0R" do?

The filters have to persist values between sample calculations as v0, v1, with l, r for stereo.
The values are stored as member variables of the Timbre class, and the 'local' versions are used as an optimization to keep them in a register (they get written back after the sample loop calculation).

[chaocrator]

I was just looking over the DX7 algorithms and noticed that some allowed an operator to have feedback. I was wondering how we could do this on the PreenFM2?

in case of sine operator waveform (as in classic yamaha DX synths), the spectrum of the feedback operator output resembles the spectrum of the sawtooth wave.
so, when recreating classic yamaha patches, the very first quick and dirty workaround for feedback emulation is changing waveform of the supposed-to-be-feedback operator from sine to sawtooth.

more accurate workaround would be using custom waveforms, recreating forms of single operator output waves with feedback values from 1 to 7.