Re: blit oscillators not being good for FM...
I think if you are doing FM and you don't want aliasing, you are going to have to upsample and filter anyway, so you may as well start with mathematically perfect waveforms and at least know what results to expect.
Anyway a bit of aliasing is nice on FM isn't it? The sound of Yamaha

If you want it to work across platforms, [midiout] and [midiin} are the most reliable options. I have a collection of vanilla abstractions to make all this easier which I am almost ready to post, these cover sysex, RPN, NRPN, and CC, and dealing with data from controllers which send relative data, but they just went through a massive overhaul because of the new [list store] methods coming out in 0.52 and I will not bother sharing them or even finishing them until 0.52 is finalized. I will probably stick these onto deken since they should be useful to enough people to warrant it, mostly aimed at easing the creation of interfaces between midi controllers and pd or using pd as an intermediary between the controller and other hardware/software but should come in handy anytime one needs to deal with midi.

@jameslo I am about to dl and check it out now. One thing though, I think I did have the modulator as the feedback operator, it's a bit hard to see because the feedback goes through inlets and outlets in the operator subpatch (the top one), and then the send and receives are outside that subpatch. Edit, you saw that. Yes having it post-attenuation and post-adsr was a change I just made, but it wasn't better before when I had it coming straigt from cos~. The thing is you are suposed to be able to get a decent saw just with the modulator so I wonder if it's something about how I was using block~ or the way I had the feedback routed outside the patch..

The switch to get the direct signal from the modulator is because as that video was demonstrating you are supposed to be able to get a saw just from the modulator alone with feedback, and a better saw from the carrier. Either way my patch didn't sound right.. I will check your patch out,,

Edit2: Yours definitely creates a saw perfectly. I noticed you defined a feedback buffer specifically instead of just using sends and receives, I think that or maybe something about the subpatch structure I had was meesing up my block size? I will have to look when I have more time later,,

@hybridoa I was thinking maybe a factory reset of the NanoKontrol, or a reset of whatever its driver might have changed for its setup.
If the data is not arriving into Pd the problem is elsewhere I think.
The Data "jumping" I have seen elsewhere on this forum and others....... along with some other Midi weirdness from the NanoKontrol2.
For other Midi controllers it really depends what you want to do. For DAW or lighting console work the BCF2000 is a good cheap option, because it can be more accurate (NRPN) and has motorised faders....... but midi controller setup is far more complex than it first seems and can be a steep learning curve unless the software you are using has built in templates for its setup.
Sysex is difficult in Pd....... anything can be done of course...... and because we are building very bespoke systems from scratch there really is very little plug'n'play available.
David.

Hi guys,

I'm trying to assign a knob from my hardware controller to control the frequency of the operators on a tiny Yamaha Reface DX.

Only "problem" is that on the actual keyboard Data List parameters there is 2 different CC Number for each operator frequency level: a "coarse" and a "fine".

For example for the OSC1 of the Reface DX, the CC 89 (with value between 0-31) controls the Coarse frequency value (integer only), and the fine frequency is control by another CC (90) with value between 0 and 99 for decimal.

(gosh, i hope i'm clear enough!!).

I would like one single knob to smoothly operate the change of frequency because the audio rendering is quite bulky when only using integer value only and the charm of FM synthesis realtime morphing is then lost...

I've tried a a patch that isolates the decimal from the integer from the midi control value and send the two values to the target CC number (89 and 90) via a [ctlout] object but the result isn't perfect really. I've put some short delay for the decimal values to be send before the integer value...

Nothing very complicated for most of you i think, but i am an eternal newbie on PureData, and i could do with some help!

Thanks for any advice guys!

Regards,

Anthony

PS: here's my patch so far:

#N canvas 398 124 739 708 10;
#X floatatom 264 182 0 0 0 0 - - -;
#X floatatom 398 173 3 0 0 0 - - -;
#X floatatom 368 172 3 0 0 0 - - -;
#X obj 355 100 ctlin;
#X obj 222 287 line;
#X floatatom 210 347 5 0 0 0 - - -;
#X obj 208 382 float;
#X floatatom 269 415 5 0 0 0 - - -;
#X obj 273 376 int;
#X floatatom 211 416 5 0 0 0 - - -;
#X floatatom 208 503 5 0 0 0 - - -;
#X obj 210 450 -;
#X obj 475 491 ctlout $1;
#X obj 490 403 + 1;
#X floatatom 563 422 5 0 0 0 - - -;
#X obj 373 295 ctlout $1;
#X obj 317 498 * 99;
#X floatatom 359 503 5 0 0 0 - - -;
#X floatatom 325 314 5 0 0 0 - - -;
#X obj 300 278 int;
#X obj 366 141 / 4.09667;
#X msg 211 243 $1 400;
#X obj 328 228 delay 500;
#X connect 0 0 21 0;
#X connect 0 0 19 1;
#X connect 0 0 22 0;
#X connect 1 0 13 0;
#X connect 1 0 15 1;
#X connect 2 0 0 0;
#X connect 3 0 20 0;
#X connect 3 1 1 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 8 0;
#X connect 6 0 9 0;
#X connect 7 0 11 1;
#X connect 8 0 7 0;
#X connect 9 0 11 0;
#X connect 10 0 16 0;
#X connect 11 0 10 0;
#X connect 13 0 14 0;
#X connect 14 0 12 1;
#X connect 16 0 17 0;
#X connect 17 0 12 0;
#X connect 19 0 18 0;
#X connect 19 0 15 0;
#X connect 20 0 2 0;
#X connect 21 0 4 0;
#X connect 22 0 19 0;

Hi, everybody!

I'm trying get into FM synthesis. As an excercise I decided to recreate some of Yamaha DX7 algoritms in PD and compare results with Korg Volca FM, that is DX7-compatible.

I took FM patch for two operators from FLOSS manual, and extended it to 3 operators stack as shown here:

But resulting sound is much more harsh in comparison with the same patch on Volca. I don't understand what I'm doing wrong.
fm_mod_stack.pd

Thanks for any help in advance!

I did think that might have been the case. I am out of my depth with this stuff, but I saw you mentioned phase above and I had heard before that the DX7 by Yamaha, for example, uses phase modulation synthesis so I figured that might have been the case. I know nothing about it, however, so will need to do some research there. Thanks so much for sharing your patch though and for the help you have provided. Am I right in saying that the FM8 by Native Instruments uses phase modulation synthesis then, as opposed to "real FM" ? And also that you can only make the operators feedback into themselves if you use PM?

@LucienR No, but the only other device I've tried is the Yamaha 01V96i.

It never occurred to me to suspect the nanoKONTROL, so thanks for that LucienR and whale-av. I configured my Yamaha 01V96i to output MIDI to PD 0.49 (yes, vanilla) and everything worked fine, which is remarkable because it generates twice as much fader data as the nanoKONTROL. But I think I'd still rather run my patch on pd-extended 0.43.4 than lug this mixer to my show, unless someone tells me that's a bad idea.

I tried that tip from Berenger (i.e. using a separate ctlin object for each controller) but PD 0.49 still hung. In fact, I can run PD 0.49 with nothing but the parent window open, wiggle the nanoKONTROL faders vigorously, then open the Test Audio and MIDI window to see that PD is no longer responding to MIDI.

I recently noticed that on Windows, the USB audio interfaces I use have adjustable buffer sizes analogous to PD's block size (I don't see a corresponding control in OS X though). The default value varies from 64 for the Yamaha/Steinberg USB driver to 512 for the MOTU Audio Console. I wrote a PD patch that does nothing except pass input to output and verified that smaller audio interface buffer sizes for the MOTU result in a proportionally lower input to output latency. It looks like that latency contains some additional overhead (~7mS) not accounted for by the PD delay, PD block size, and audio interface buffer size. What accounts for the additional overhead? Is there any interaction between PD block size and audio interface buffer size? Is there a better way to choose the optimal audio interface buffer size than trial and error? Does that size depend on the specifics of your PD patch?