DX7 problem/ feedback generator

    Dec 03 2011 | 6:23 pm
    I'm interested in creating a DX7 keyboard, everything was alright but now i face a little problem :
    I have a picture of how the algorythms looks like, but i can't figure out how to make the ones that feedback themselves...a patcher can't have his outlet as an inlet.
    I joined a picture to be clear : i m talking about the generator 6 in the first algo, the 2 in the second ...etc
    thank for your help !

    • Dec 03 2011 | 6:48 pm
      Hi I would use a send~/receive~ pair, as follows. It appears that you should restrict the feedback amount to < 1. otherwise 'chaotic' noise ensues - but you might like that....
      (must dig out my old DX9...)
    • Dec 03 2011 | 6:59 pm
      i am not exactly sure, but i think it is not a feedback, just the (unmodulated) ops modulating each other.
      otherwise figure 7, where an op is modulating itself, wouldnt make much sense.
      you could realize that by using a second instance of those ops.
    • Dec 03 2011 | 7:11 pm
      Hi I assumed that the DX graphic represents Carriers along the bottom line, with Modulators above them. I have no idea, however, how Yamaha implemented feedback modulation.
    • Dec 03 2011 | 8:04 pm
      In the theory of FM synthesis, 'feedback' refers to when a modulator modulates itself. That's what is shown in figure 7, and figure 1.
      Brendan's example shows how to do it in MSP, with a signal vector of delay. Not sure why you would need a second instance of the ops..?
    • Dec 03 2011 | 8:09 pm
      because the original instances output might already be in a modulated state?
    • Dec 03 2011 | 8:32 pm
      Of course, that's correct; so the alternative would be as you suggest Roman - a duplicate modulator, to modulate 'itself'
      patch EDIT: the modulation INDEX is a now function of the entire mod output
    • Dec 03 2011 | 9:13 pm
      which will also eliminate the problem a vector delay otherwise would cause.
      but it still would be nice to hear from someone who knows how it actually works in the original synth.
    • Dec 03 2011 | 9:42 pm
      I just now noticed that the new gen~ examples include an instance of 'feedback FM', which may be of interest to the OP. This time with only the problem of a sample delay...
    • Dec 03 2011 | 10:37 pm
      Thanks for those ideas i'm going to investigate that a bit
      I thought of the delay too, but just don't really know how to implement that.
      n00b_meister your solution seems good but on max6 it seems that there is a problem between the poly~ and the send~ so....maybe i should just try with a wire.
    • Dec 03 2011 | 10:52 pm
      Yeah, seems there is a problem with send~ receive~ in poly~. Use tapin~ and tapout~. Here's Brendan's solution, edited:
    • Dec 03 2011 | 11:22 pm
      @laloutre I think what your referring to is the fact that, inside a poly~, sends and receives need unique names; name them as follows: [send~ #0_mySend1] or [send~ #0_mySend2] etc - the important bit is the #0_
      I'm on Max5 and that's what I do, don't know about 6
      ps I've been having loadsa fun with feedback FM this evening - assisted by some ice-cold Heineken:
    • Dec 03 2011 | 11:49 pm
      @Brendan Cheers ! Thanks and FM is surely more fun with a little beer ! :) It is a known bug of max6 about poly~ and send~ so...
      @goodparleyandorfing Thank you but is this going to make a delay in my signal ? Will this affect what i ll hear ?
      ByTheWay here is my version of FM synth tell me what you think i know this is a bit complicated and if you have some ideas to improove it (make it faster) !
    • Dec 04 2011 | 12:17 am
      oh i should have precised that i used the gen object(no the one of max6) used in the percolate lib !
    • Dec 04 2011 | 1:16 am
      You might need to repackage this synth; when opened it also opens around 300 subpatches (called "init"), which made my machine really slow down - make sure all windows except the main patch are closed before saving and zipping.
    • Dec 04 2011 | 3:07 am
      - will the vector delay what you hear? yes, of course will it. but there is no way to avoid it when you need a signal feedback.
      - make it faster for example by using individual poly~s for every single operator. that way you will also be able to do the vector dela trick outside the poly patchers. :)
      post scriptum:
      [r #0pitch] wont work for two reasons.
      dont use patcher names like "sine", it is too generic.
      after your main patch loaded about 2000 windows i had to force quite max. :) maybe you close your poly windows before saving the main patch.
      i would not use different patchers for the different "algo"s but use router or matrix~instead. at the moment you would loose all the synth parameter settings when changing to a different algo.
    • Dec 04 2011 | 1:18 pm
      i get the impression the op is on max6.
      while it is important and useful to get to grips with the MSP signal vector delay issues for your general max patching knowledge, that method in this situation is not advantageous at all. it is effectively a 'deprecated' method if you are on max6. we have gen~ now, and can do single sample feedback, so we might as well use it.
      the best fm + msp tutorial i have ever seen is the basic FM walkthrough in the Peter Elsea package, downloadable from http://cnmat.berkeley.edu/link/1319
      i attach a quick demo of the peter elsea idea ported to gen~ with single sample feedback chain for oscillator self modulation. (max6 only).
      hope it helps.
    • Dec 04 2011 | 5:06 pm
      @pid Thanks. i'll have a look, it is true that we can now use Gen~, but i didn't look at it yet.
      I've made an other pack with my synth because it is true that i sometimes forgot and save with an opened patcher so multiple pop-up at the begining.
    • Dec 04 2011 | 8:09 pm
      Hi I was hoping you'd drop in - is your patch suggestion viewable in Max5? Or totally dependent on Gen? I ask as I'm curious to see your realisation of Elsea's excellent work.
    • Dec 05 2011 | 11:54 pm
      hi brenden.
      you could 'view' it in max five, but bad news is, it totally relies on gen~ as the oscillators are in gen~. so in five nothing interesting is there. however, you'd be able to open in max6 runtime and look inside patches.
      however, i perhaps shouldn't have used the "port" word. it was a sunday morning coffee patching session and is very basic and totally unoptimised, just for demoing the feedback. just two elsea modules used.
      it is a nice example of just how simple gen~ is, though. i am finding it easier and more logical to patch in gen~ than msp by far, because singleness of purpose and less baggage. and less cpu, which is quite amazing.
    • Dec 06 2011 | 12:10 am
      hi pid,
      "port" I can live with :)
      might try the runtime trick thanks
      either that or the "upgrade to 6" trick LOL