UVI Falcon - hybrid instrument - version 3.01 released - rumors, ads, praise, mud wrestling and off-topic inside!

[arachnaut]

A brief discussion about Falcon design from a hacker perspective:

If you open a factory preset and save it somewhere, you can look at the preset XML and it might help you understand how to do certain things.

For example, the typical preset is an 'object-oriented' structure with the following typical hierarchy:

Code: Select all

Program
  ControlSignalSources (eg Macros)
  EventProcessors (scripts, which may be in-lined)
  Inserts
  Layers
      Layer
        ControlSignalSources
        BusRouters
        Keygroups
            Connections
                SignalConnections
            ControlSignalSources
            Inserts
            Oscillators

You can put scripts in-line using the XML CDATA escape sequence - that is a way to write meta information inside XML that uses plain text instead of structure elements.

You use it like this example from the preset Ambient Pad Quencer which sets up some colors:

Code: Select all

        <EventProcessors>
            <ScriptProcessor Name="EventProcessor0" Bypass="0" API_version="15">
                <Properties OriginalProgramPath="$Falcon Factory.ufs/Presets/Experimental/Ambient Pad Quencer.uvip" ScriptPath="$Falcon Factory.ufs/Presets/z_key colours/key colour Amb Pad Quencer.lua"/>
                <script><![CDATA[---------------------------------------
-- Ambient Pad Quencer
---------------------------------------



-----------------
--key colouring
-----------------
local keyColour1="#022964"
local keyColour2="#6893de"


for i=12+12,47+12 do
	setKeyColour(i,keyColour1)
end

for i=48+12,84+12 do
	setKeyColour(i,keyColour2)
end


]]></script>
                <ScriptData/>
            </ScriptProcessor>
        </EventProcessors>

You can see from this hierarchy that oscillators are at the bottom of the structure and they are properties of keygroups.

This design decision is at the heart of my grief with Falcon.

While I like Falcon and it's potentials, this part is not to my liking.

Here is why.

A keygroup having oscillator properties seems backwards to me. I can certainly understand how and why an oscillator may have a keygroup. Every synth I know does something akin to this. In an analog modular we have a single keyboard and we plug its control voltage into modules.

But we don't usually have keyboards where we plug in black boxes of instruments over certain ranges of keys. (Except for the Mellotron which is the only thing like that that I can recall).

Theoretically, Falcon is like having a separate Moog synthesizer on every key. Each key can have it's own Moog with its own settings.

That design implementation does not take into account the practical typical usage of only having a single Moog or two over a keyboard range. With that approach I can twist a knob and the whole keyboard range sounds different. In Falcon, I will have to twist knobs on each virtual Moog separately.

One could accomplish the same thing by having the Oscillator at a higher level in the structure and assigning multiple keygroups to the osccillator. If we want an oscillator per key we can do that.

But that latter way allows us to change the sound of keygroups much more easily and practically.

This discussion helps me to understand the why, which helps me understand how to do things better.

I wish that the design of the keygroups allowed a bundled display of all the oscillator commonalities instead of just showing 'Multiple selections'. By aggregating all the common elements and showing them and allowing them to be changed en masse I would be happy.

But I really think that a better approach would be to reverse the object hierarchy between keygroup and oscillator.

I know there is little one can do to change an already-designed piece of software, but at least we can understand it better and that will help us avoid problems in using it.

[arachnaut]

Works now, thanks!
Interesting sound

That's what I write when I don't like something!

Hahahaha.
It's not a sound I would come up with myself, but that's what I like with hearing other peoples creations

I have used these samples in Live's Sampler and for Rapture Pro and Nuance. All those presets are freely available on various forums.

In this case, the instrument exposes all the major sampler parameters of Falcon and lets you turn them on and off individually or in parallel. It was mostly a learning tool.

I would expect people who download it to tweak it and adjust the envelopes and levels to their own liking - I did practically no tweaks beyond getting the samples in place. They probably should overlap, too, since the velocity ranges sound quite different.

While I was making it, Falcon crashed a lot when I moved keygroups around: copying and pasting or deleting.

And I was surprised when the keygroups were not organized in order. I made them in sequence, but they appear in some sort of random order internally.

[EvilDragon]

But I really think that a better approach would be to reverse the object hierarchy between keygroup and oscillator.

It won't happen, though.

Currently because keygroups can have more than one oscillator you can build per-keygroup round robins, which is extremely beneficial for sampled instruments (or even when you want to spice things up a bit so that one key doesn't sound the same, since oscillators don't need to be of the same type within the keygroup, at all).

It's obviously a design choice, so I don't see it changing. Embracing its strengths is more beneficial.

[bmanic]

I can see the benefits but this hierarchy is definitely something that will divide people.

However, isn't there a way around this? Perhaps we could have some assignable macro controls over every single osc parameter and then have those be able to be saved so that every time you create a new oscillator you have that unified macro control over it and thus immediate control over common parameters without having to manually assign and tweak everything. Couldn't this be a workaround?

The hierarchy should not be changed IMO, it is there due to good reasons as was previously stated but the handling of common parameters, by default, should be possible to change.

[arachnaut]

... Perhaps we could have some assignable macro controls over every single osc parameter and then have those be able to be saved so that every time you create a new oscillator you have that unified macro control over it and thus immediate control over common parameters without having to manually assign and tweak everything. ...

This already exists in the hierarchy.
The "ControlSignalSources" is at the very top of the hierarchy.
It just can't be connected to global stuff very easily.

[Sampleconstruct]

I know there is little one can do to change an already-designed piece of software, but at least we can understand it better and that will help us avoid problems in using it.

It took me about six months after getting into MachFive to accept and internalize the hierarchy of oscillators/keygroups/layers/programs and by wasting dozens and dozens of hours by re-programming the same thing manually, I finally decided to always approach a new patch strategically and view the obvious limitation as a strength. It's a sampler-based keygroup/zone design with the option to have an entire synth module per key/round robin/velocity zone. So with the strategical approach I am about as fast now as you will be with your hacking-presets-approach, copying/pasting/re-assigning can be fast if you develop a robotic workflow.

[arachnaut]

The experimenter in me does not have a strategy when it approaches a patch.

[Sampleconstruct]

The experimenter in me does not have a strategy when it approaches a patch.

Then just go the hacking route instead, if it helps you, fine.

[wagtunes]

If you've ever worked on a totally open ended modular synth, Falcon really isn't all that different. Personally, I don't have a problem with the architecture but I guess it all comes down to what you're used to.

[thetechnobear]

thats the thing with hierarchies, they make things simple for one view, but tricky for others...
(if you flip the hierarchy, you will make something else difficult... and networks are difficult to visualize)

hmmm if script knobs could be modulated, then you could probably some do using a script. simply iterate thru the keygroup at the layer level, and if the oscillators are truely identical, then you can optimise as the paramIdx would be the same on them all.
(unfortunately we can't modulate the script controls... so this would be limited to midi control)

... did UVI say if script controls will become modulatable in the future?

[dmbaer]

My new FAQ-thread is the total opposite of “scattered“ - one post in on sticky-thread containing all the essential info I can compile.

This will be much appreciated, Simon. But where is the thread? I could not spot it in the Instrument list.

[Sampleconstruct]

My new FAQ-thread is the total opposite of “scattered“ - one post in on sticky-thread containing all the essential info I can compile.

This will be much appreciated, Simon. But where is the thread? I could not spot it in the Instrument list.

It is linked in the first post of this thread.

Here is the link again, it´s a sticky thread in my patchpool forum, not in instruments:
http://www.kvraudio.com/forum/viewtopic ... 0&t=451038

[arachnaut]

But I really think that a better approach would be to reverse the object hierarchy between keygroup and oscillator.

It won't happen, though.

Currently because keygroups can have more than one oscillator you can build per-keygroup round robins, which is extremely beneficial for sampled instruments (or even when you want to spice things up a bit so that one key doesn't sound the same, since oscillators don't need to be of the same type within the keygroup, at all).

It's obviously a design choice, so I don't see it changing. Embracing its strengths is more beneficial.

I've thought about this and I don't see that the architecture makes a bit of difference.

Any way you look at it a key event is used to select from a round-robin pool. In one approach an instrument on a layer does a sample read, in another a keygroup writes a sample to an instrument. Multiple layers can give you multiple instruments. Whatever causes an instrument to be selected would apply in either case. It's totally symmetrical.

And I'm not expecting any architectural changes to occur from any of my comments.

I'm stating that I would find common instrument control displays on a selected range of keygroups to be a very useful and welcome addition to the way Falcon current works.

If we don't get that, we can resort to editing the common controls manually - which I find easier than using manual mouse selections, at least in some cases.

The choice is ours, we can embrace our individual strengths, too. So many people don't use text editors at all. It is a useful option to have in one's bag of tricks. I think I learned more looking at a factory preset in an hour than I did in using Falcon for the last two or three weeks. But I'm a software guy, not a musician.

I think I've said more than I should on the topic, at least until I get to know Falcon better... So I'll lay off this topic for a while and let others speak up about it. I guess most people post from work, the weekends seem quiet.

Oh, and in case I didn't say it or I come across as negative, Falcon is fantastic!

[arachnaut]

...
I think I've said more than I should on the topic, at least until I get to know Falcon better... So I'll lay off this topic for a while and let others speak up about it.
...

So why am I back posting so soon?

Well, I just went through every factory preset and didn't find a single one of any sample complexity. At least nothing even remotely like the Karplangor preset I posted a while back (which has 198 keygroups). I am not talking about patch complexity or quality, just the complexity of the mapping of the samples and keygroups. See the picture below for an example of what I mean.

Some had a few keygroups, some had a few layers, some had a few velocity levels.

Most had a single keygroup and at most one or two samples.

Yannification, I think had the most samples (11), but no velocity levels and only a single layer. No preset filled the 'List' column with samples whereas mine needs to scroll down three times to see them all on a HD display.

I used my laptop, which is pretty slow, and I would immediately know if there were a few because the one I did with 198 keygroups takes quite some time to load - about a minute. Just watching the keygroup counter takes a while. No factory preset loaded slower than an eyeblink or two, and I never saw the keygroup counter flash slowly.

So I think there aren't so many people out there who have tried to make a large multi-sampled, multi-level, multi-layer, multi-instrument preset in Falcon.

As one who has, my experience was already stated as a few complaints, but let me mention a few other things that make this sort of preset hard to do in Falcon. Perhaps some user conveniences could be supplied to help these problems.

1) Deleting large sample groups usually crashed Falcon. I have encountered this so many times making the preset I referenced a few posts back. No doubt these sort of issues will get fixed, but they may only show up if one uses quite a few samples and/or layers. I submitted an easily reproducible example to UVI support.

2) When you modify a keygroup you have to use the mouse to select it. When you try going through 198 keygroups with mouseclicks, you will no doubt bump a few accidentally and change the velocity range. It would be nice to be able to select the next keygroup with a tab key. Arrow keys nudge the keygroup.

3) It would be nice to be able to sort samples by velocity and/or key.

4) If you want to select a range of keygroups, you can only do so with control clicks. You can not use a mouse drag. You can do so if you move a keygroup to expose a 'hole' in the mapping area and use that hole to start the mouse click and then drag an area to lasso a group. (I'm talking about mapping areas that are totally filled - all notes, all velocities, so no holes).

5) The resolve overlapping tools work somewhat oddly. I don't know how they work, but they don't work as I expected. If I had a few overlapping velocity areas, like from an accidental nudge, I expected the resolution to automatically adjust and nudge them in place, but it did not do that at all, it totally wrecked the key sample.

6) If you do need to make a change after setting up the keymap you need to go through each one and make the change - it is very easy to miss one. As you click on the keymap, you will probably nudge a few of these groups by accident and have to go back and place them properly. Since most changes that I made affected every sample in the instrument, I would sorely like to be able to make changes like that globally. But I suppose I already made this complaint clear by now.

7) Using the Tree View to modify the topmost macro of a set of keygroups results in a random number of the macros in the group getting adjusted properly and the rest get ignored. I posted pictures of this a few posts back.

I use a PC on Windows 10, maybe the Mac user has it a bit easier.

And as I mentioned before, Falcon is fantastic and I recommend it to all my friends!

Here is an example of what I mean by a complex keymap:

[Sampleconstruct]

I didn't use many sample for my Falcon factory sounds, but I am currently doing some very sample intense patches with hundreds of keygroups and did so back with MachFive and it all works/worked smoothly, none of the horror you are describing has bothered me (apart of the lack of batch editing oscillators), so to me it seems you're fighting with a Falcon rather than embracing and feeding it