DX7 problem/ feedback generator
Hi
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 !
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...)
Brendan
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.
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.
Brendan
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..?
because the original instances output might already be in a modulated state?
Of course, that's correct; so the alternative would be as you suggest Roman - a duplicate modulator, to modulate 'itself'
Brendan
patch EDIT: the modulation INDEX is a now function of the entire mod output
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.
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...
Yes
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.
Yeah, seems there is a problem with send~ receive~ in poly~. Use tapin~ and tapout~. Here's Brendan's solution, edited:
@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:
Brendan
@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) !
oh i should have precised that i used the gen object(no the one of max6) used in the percolate lib !
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.
- 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. :)
-110
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.
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.
@pid
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.
Brendan
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.
best.
hi pid,
"port" I can live with :)
might try the runtime trick thanks
either that or the "upgrade to 6" trick LOL