Thought we could have a big thread about FM. Seems like a topic that has both perpetual interest and indelible confusion.
This is in the Build section because I am hoping there will be lots of practical examples, but I think if you have any interesting videos or musical examples feel free to share.
Also this thread is for both phase modulation and frequency modulation. The reason being phase modulation is already called FM by the majority of musicians and it’s reasonable to use the common parlance.
Here is a video I made disambiguating the two I made a year ago and while i have posted it before, I think this is the proper place for it.
I’m sure I said this before but again, excellent video. Very concisely explains the differences between the various forms of “FM” We need something on linear vs. exponential FM as well.
Yeah the Mindphaser is really interesting, He uses a very carefully calibrated wave folder to emulate a fract(x) like the happy nerding FM aid. I think this could be pretty easily modeled in Audulus even is the whole point of the module was to make a typically digital synthesis type happen in analog.
I thought this might be interesting to some. It’s a single FM algorithm (two short stacks with a crossfade) with modulation envelopes inspired by the Digitone. The amp envelope uses a low pass gate to trim off some of the aliasing, but you can create a surprisingly wide range of sounds with just this single configuration.
I don’t think so. The 3.0 version was the last one I did. After the Sandcastle, I focused more on building single operator modules so that you could combine them using whatever algorithm you liked.
Here’s a set of patches I put together to explain PM synthesis using the uPopDX module uPop DX Tutorial Pt 1.audulus (20.2 KB) uPop DX Tutorial Pt 2.audulus (377.7 KB) uPop DX V1.0 demo.audulus (717.3 KB) uPop DX V1.0.audulus (24.3 KB)
And, of course, it is a beautiful app. Even less confusing than other FM menus. Still, I find I have to start thinking like an electrician and, in that case, instead of imagining the routing it is better to deal with it directly. Why put an extra step in between?
But, Audulus can get pretty CPU heavy fast doing this – as @stschoen has mentioned a number of times. Whereas with KQ Dixie I can get numerous copies of it as an AUv3, while it remains so easy on the CPU.
It makes me come back again to the idea that I wish Audulus had 2 modes. Some sort of mode where it could run bare bones locked into one operation. This is the idea that you almost produce a plugin using Audulus, but the plugin is actually not an instance of Audulus, but simply the synth you made. This has got to be an approach to solving the CPU challenges. Keep in mind, while sometimes you can get a few tools going in Audulus to compliment a rack or some other setup, the future feature set needs to beware of the limitation that even if we get sampling going in Audulus 4, it may mean you can really only be doing that with an ES-8. You can’t also be running an FM synth with 7 operators, a delay, some reverb, etc,. etc.
One thing does come to mind though. Visual feedback is so crucial. We need more tools to produce sections that animate what parameters are doing. Even the basic animations in Dixie are vital. Feels like the move could be to take a step back, rather than rushing forward.
The two parts of Audulus that make up the bulk of the CPU load are the DSP engine and the User Interface. Because Audulus is a general purpose audio engine, it’s not highly optimized for any particular operation. Many Audulus patches would run with a smaller CPU load if the code were compiled for a specific task, but unfortunately that’s not possible with iOS because Apple doesn’t allow on-board compilers for security reasons. It would be possible to compile a specific patch on the Mac, but having done so, you would not be able to load it on an iOS device since it contains executable code. With a product like KQDixie the optimizing is done when the app is built so it can be more efficient with CPU cycles. The UI is also processor intensive because of its flexibility. The ability to drag modules around, connect virtual wires, and freely zoom in and out comes with a price. A fixed UI involves much less load on the CPU.
That being said, @Taylor is always interested in optimizing performance and you should see significant improvements with version 4. Audulus already compares favorably with other similar tools on the Mac such as Max and Reaktor and I think it has no real competition on iOS.
I have no idea how you manage to have such technical points about almost every concern I have had.
This is what I figured. Is there a compromise to be had somewhere? I have found that in my experience a lot of what I want to do or what I am looking for in a product often tends to be characterized as “something that just isn’t done,” or there is usually some accepted barrier in the way of some key elements that could really open up territories. I can’t think of a more common scenario in terms of ‘innovation’.
Much of what kills my momentum are the technical walls, which are just there because people have been putting their energy into marketing and buying a lot of junk. I am over the moon about Audulus, but I really wish Apple would just say, “okay, we made it big. Why don’t we stop pandering to the masses and spend some time giving back to the core nerds who made everything possible for the masses, so that the nerds can have fun for a while and develop the next stage for technology?” Then you hand the stuff out to the consumers after things have been renovated a little. If Apple doesn’t make this change, there may be some bright people who will turn away from computing – bored with the pretty graphics and ‘sense of community’.
I’ve spent most of the last 45 years involved with software in one form or another, both as a hobby and a profession. Some of it stuck.
As is the case with most things in life creating an operating system is a balancing act between competing factors. With iOS, Apple chose to put security high on the priority list. The choice to only allow apps to to be installed from the App Store after the code has been verified makes it very difficult for a user to install malicious code. Of course it also means that Apple has total control over what apps can and cannot do and which apps can be installed. Because it’s not practical to validate code that might be generated from any on-board compiler, Apple chooses not to allow them on iOS. This is not the case with Android which does not prevent the user from installing arbitrary code. As a result Android has had several publicized cases of malware. Originally apps had no ability to communicate with each other and only limited abilities to interact with the OS, but that has changed as iOS has evolved and apps now have greater freedom to interact with others and the underlying OS.
As far as walls are concerned, I think Apple has done a lot to make the technology available. Apple’s development environment, the documentation, a wide range of tutorials and other tools needed to develop applications are freely available which is not the case for the Windows OS. I believe they realize that their future depends on independent developers and for the most part they do a good job in supporting them and encouraging new ones.
Originally it was not possible to install an app on iOS other than as a registered developer or from the App Store. As of 2018 that is no longer the case, and it is possible for you to create an app via Xcode and install it on your own device. You can’t distribute the app, but you can run it on your own iOS devices. Of course you still need to be familiar with iOS. It might be possible to develop a framework that would allow someone with limited programming experience to build plug-ins, but it would be a difficult task and would probably have a limited market. If you’re interested there is an open source audio framework called AudioKit that is freely available that makes using audio in iOS much simpler. It was used to build the free Synth One app as well as the Digital D1 app and many others.
If you really want to build your own apps it’s possible to do so without spending a fortune (assuming you have a Mac.) If you can code using Audulus, you can learn to program in other languages.
I would even go so far as to say that Audulus bests its competitors with all that it is capable of doing, while still maintaining a reasonable price point. Also, having the community, which is so good at welcoming new users, and sharing knowledge and inventions freely pushes it up over the top, in my opinion. I don’t see that type of innovation anywhere else, and I was shocked and kinda disappointed to find out that users of Max actually make patches and utilities so they can monetize, keeping the knowledge all to themselves, like trade secrets.
People can do what they want, but that promotes an ‘every man for himself’ kind of environment, and I don’t think any of that adds up to even a fraction of the level of awesome where my mind elevates Audulus, as a whole. It makes me feel even more grateful for all the kind and generous people (you all know who you are ) who have given so much of their time and energy to help myself and many others like me to better understand, and become a more functional and contributing member of this app and community
It’s true that Max allows you to create a finished app which can then be sold. I’m not sure that this is necessarily a bad thing. In many ways it’s similar to programming in any other environment. In the same way that there are a mix of paid, free and open-source apps created with other programming tools, Max allows flexibility in how Max apps are distributed. After all you have to cover the cost for Max. Max and PD both have large and very active user communities. The biggest issue for me with Max (other than the steep price tag) and PD is the complexity of their approach to modeling sound. While in some cases it allows you to do things that aren’t practical in Audulus, it makes it much more difficult for a new user, particularly someone not familiar with programming, to start making music. I initially chose Audulus for it’s simplicity, flexibility, beautiful UI and outstanding performance, but I stuck with it because of all the fine people that contribute their thoughts and creations to our little community. Like you said:
I wanted to throw something in about phase vs. frequency modulation since one finds a lot of internet discussions where someone will say that the DX7 does phase modulation and not FM. To the best of my knowledge, the following is correct (please correct me if I am mistaken).
When working with sine wave carriers and modulators (which is what Chowning was working with and which is how the DX7 works), phase modulation and “traditional” FM are mathematically equivalent. Either phase or (angular) frequency is the derivative of the other (I can’t remember which direction the relationship goes) (when working with sine waves).
From what I understand, working in the phase domain has benefits (compuatational efficiency?) so that was used. Apparently, lots of things that we call FM (including with radio signals) actually uses phase modulation. So, phase modulation is the mathematical technique being used to accomplish frequency modulation and achieves the same result as would be achieved by performing straight frequency modulation.
The phase vs. frequency modulation debate (with regards to sine wave based systems) seems to be making a distinction without a difference.
We need something on linear vs. exponential FM as well.
) who have given so much of their time and energy to help myself and many others like me to better understand, and become a more functional and contributing member of this app and community 
