Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group/Zone/Wave proposal #107

Closed
rudeog opened this issue Feb 9, 2021 · 12 comments
Closed

Group/Zone/Wave proposal #107

rudeog opened this issue Feb 9, 2021 · 12 comments
Milestone

Comments

@rudeog
Copy link
Collaborator

rudeog commented Feb 9, 2021

I'd like to offer a proposal for how we organize the hierarchy of objects. Hopefully this will start a discussion, as I know there are many good ideas that other people have. This does not have to do with how we map effects or do audio routing across these levels. This is more just for how things could hypothetically be organized and triggered. In SC1, there were groups and zones. Each zone could contain a wave (sample). In addition, each wave could be chopped so that different parts of it play depending on key.
In SC2, it seems like this was altered a bit. Anyway I think we can agree that the SC1 layout was preferable.
I'd like to propose that we have not 2 but 3 levels: group, zone and wave.

  • A group could contain multiple zones
  • A zone could contain multiple waves
  • A group could have associated triggering conditions eventually (kind of like kontakt with key switches)
  • A zone could have start key/end key/root note/ upper and lower velocity, mute groups, and also a triggering mode for waves in the zone (discussed below)
  • A wave could have its own ADSR, start and end point, loop points, (possibly even fx per wave)
  • A single sample in a zone could be split into multiple waves in the zone (kind of like for SC1 where you can split by key)

So triggering for waves in a zone is where it could get interesting. We could have the following modes:

  • All the waves are triggered when the zone is triggered (eg you are building a drum sound with different attack and decay portions from different waves, or you are using one wave as an attack sound and another in loop mode as a sustaining sound). Could also extend to different ways to mix the sounds like eg ring mod.
  • random/round robin - each wave is alternately triggered
  • key mapped - waves are mapped sequentially to keys in the zone (eg you are cutting up a drum loop)

Anyway, just an idea

@baconpaul
Copy link
Contributor

I very much like the idea of having the hierarchy support round robin waves on a single key. Having an multi-wave 'zone' which was otherwise treated as a single thing for other routing seems smart. But I'm not a sampler expert.

I agree that most folks seem to think the SC1 model was better than the SC2 one though!

@mkruselj
Copy link
Collaborator

mkruselj commented Feb 10, 2021

This is similar to UVI Falcon, in that one zone can contain multiple oscillators/samples. However, they share all the zone processing (envelopes/LFOs/FX...), for obvious reasons of efficiency. I suggest we follow that method too. Let zone be the lowest level at which processors are added. Then waves would just be alternated as per triggering rules.

SC2 actually never really implemented groups properly. There are layers A-H, but they are introduced with a different purpose (to do velocity crossfades and also have two trigger conditions).

I think anything we do should support both SC1 and SC2 ways of things, if we want to ensure patch compatibility. If not, I guess blow it to smithereens then. But do we really want to piss off old users who likely have a bunch of SC files laying around? I think not.

The main problem here is, I can't see how we could merge SC1 groups with SC2 layers. They're quite different in their intention.

@djtuBIG-MaliceX
Copy link
Contributor

I think this could work. Just would need to establish the "upgrade pathway" for existing patches to map to the proposed hierarchy.

@mkruselj
Copy link
Collaborator

mkruselj commented Feb 14, 2021

Let's consider this: in SC2, you can overlap zones within a single layer. You can also do velocity splits/crossfades. And then you have layers A-H which can do exactly the same thing, except it's between multiple sets of zones. And there are two additional rules for triggering those layers (Layer Ranges on Part tab).

This just seems completely redundant (apart from the layer ranges thing)... So let me try to put some sense into this all. Maybe this is what we could do:

  • Keep the multi(>group)>zone hierarchy of SC1 for sure. It was good.
  • Add waves as children of zones, as suggested by @rudeog, however I would really like to reaffirm that it should only be samples to round-robin alternate between, rather than complete copies of zones (keeping it simple!)
  • Add another optional level above group, which would be Part from SC2 (a collection of groups and free zones). This is basically an "instrument", a single patch. Say you load a SFZ or an Akai patch, it would load as a part, with multiple groups and all.
  • SC1 did not have the Layer Ranges thing. SC1 did not have the layer velocity split/crossfade thing. However SC2 sucked by only having 8 layers (groups). So, in order to support loading SC2 patches, we should, in my mind, convert SC2 layers to SC1 groups, and then retain layer ranges/vel split/xfade features, but they should NOT be limited to 8 groups only. So, each and every group in SCXT gets its own Layer Ranges thing, and then we add Velocity Split/Crossfade pools.

To elaborate...

image

Vel Split/Xfade gives you these options to split/xfade between nothing, or between A-B up to A-H (takes all the in-between layers into account, so you can have an 8-way xfade, say). Instead of this, in SCXT we would "create a new pool", then pick which groups we want to have as a part of that pool, and then we get these options for splitting/xfading, equal gain or equal power, and distribution skew.

This to me seems like the only legit way to ensure support for both SC1 and SC2.

Obviously, we will have to reinstate SC1's group editing:

image

This allows us to either completely override, or offset the parameters for all zones in a particular group (offset works no matter which effect is loaded into whichever zone, IIRC, which can create some really weird results!). Group LFO is also important, this is our "one thing for all the voices" thing.

We should also definitely increase the number of LFOs, and filter/FX slots, too.

@rudeog
Copy link
Collaborator Author

rudeog commented Feb 16, 2021

We know that SC1 was popular. How popular was SC2? To me it seemed hardly usable (in that it seemed to have some serious bugs, not from a usability standpoint). I'm only asking because I am wondering how critical it is to support upgrading SC2 patches to SCXT.

@baconpaul
Copy link
Contributor

My read - albeit somewhat uninformed - is there’s some sc1 devotees out there but if SC2 is harder to move or remaps incompletely that would be ok - it’s not like surge 15 with thousands of patches

@mkruselj
Copy link
Collaborator

I think it would be nice to support SC2 patches too. It's pretty obvious Claes was evolving it into something bigger, but it's incomplete. We can make it complete, while retaining all the great things about SC1, I think.

@rudeog
Copy link
Collaborator Author

rudeog commented Feb 17, 2021

Yeah, but the point is, will there really be SC2 patches out in the wild, given that there were never really any SC2 users. I get that we should support features that are in (or were destined to be in) SC2, but if we have to jump through hoops to support a patch file format that was never really used (or maybe used by a small handful of people), then I think our time is better spent on making sure the SC1 patch format can load (as there are arguably a lot more sc1 users).

@mkruselj
Copy link
Collaborator

mkruselj commented Feb 17, 2021

Are you sure there never really were any SC2 users? I'd still not want to dismiss them. From what I noticed there was actually a solid number of people who combined SC1 and SC2 based on what they wanted to do...

@djtuBIG-MaliceX
Copy link
Contributor

djtuBIG-MaliceX commented Feb 21, 2021

My take is:

  • Load SC1 patch (scm/scg, where patch xml version < 2.0.0) => SCXT patch
  • Load SC2 patch (patch xml version >= 2 && < 3) => SCXT patch
  • SCXT patch xml version should be >= 3

Supporting upgrade pathways for both can easily be segmented as required, whichever applies.

@JuliusLC
Copy link

JuliusLC commented Jan 1, 2022

SC2 always remained on Beta stage. Last one was a 0.6.x, wasn't that?
I, as user, would prefer to keep tools limited but in a single page. I can't even remember commercial libraries relesed for Shortcircuit and after so many years, it's very hard to find Presets/sounds all over the internet created for Shortcircuit.
It'd be great to be able to open SHC1/2 files, but backwards compatibility shouldn't be a must.
Most of the functions of SHC1 were included in SHC2, the only big problem was the unstability of SHC2. I used to create patches on SHC1 and to play patches with SHC2.
This is my last email to Claes about SC2

_

SC2 beta...
Julius @ Wikter wikter@gmail.com | Julius @ Wikter wikter@gmail.com | mar, 6 nov 2007, 23:30
Julius @ Wikter wikter@gmail.com

Hi Claes,

I'm Julius // Wikter, a contributor to the V1 of shortcircuit development/betatesting (before wikter@jazzfree.com).
I've been trying the second beta since it was released, but I never started to send you feedback due to lack of time.
Well, I've seen that Sc have become free, and that's a good thing, because I've been sharing for years my collection of freeware and I always had to kept Shortcircuit apart.
Then, I think that for now it's time to send you my impressions about this one.

1.- Chainer let the interface offline, there are the sliders but they didn't respond. Cant load a sample, patch or multi.
2.- When I press the "used" on the library list and there's no used samples, app crashes.
3.- Loading in Chainer: SC2 Refreshes database each time it's started.
4.- I need modulation options on Part window (LFO, EG's)
5.- I can't fill any text/number inside any of the boxes (shc1 works).
6.- What about trimming samples in memory? It would help on loading samples to memory, altough the original wave were kept as is. With a "reload wave" option. Of course, if things beyond Start/End are taken away from memory it isn't a need.
7.- Part settings are not stored when patch is saved. Effects settings are lost after reload.
8.- For Synth capabilities (I think it's something like Surge oscillators as they sound really cool) a common Part EG+LFO are a must, and Old Shc1 EGOverride is a very interesting tool. Maybe this could be an interesting option for release a not for free V2.0. The way synth layers can be placed and managed using "Pad view" is unique. Of course a region should be played with no wav, using only the 2 filter slots as oscillators... or placing an advanced option to use "zones" as pure VA oscillators.
9.- Some gui problems... Lists not shown when reopening the interface (first time it's shown it works fine). Also opening the interface produce glitches. Well, it seems that the lists can be usable after loading a patch (loosing patch fx settings)... or by reloading .fxp (keeping effects ok), maybe it's a host dependant error.
10.- Well... NOT so often refreshing database is a must.
11.- And what about routing FX1>FX2>FX3... ¿? Maybe it's possible, but I haven't used it already.
12.- In any case, Filter Override was a very powerful tool... And I can't shoot the filter envelope of the group from the group!!! Also in Shortcircuit1 the "overridedEG" dissapeared from the "group editor" modulation matrix.
13.-

Here you got a "synthesis" patch and the song project created with Reaper and Shortcircuit v1+v2 (+DrumaticVE)( http://www.reaper.fm ) each on a rar file.
Thanks at all.

_

@baconpaul baconpaul added this to the After DTR milestone Jan 20, 2022
@mkruselj
Copy link
Collaborator

We have honed in on this (multi > part > group > zone > sample and variations) , so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants