Shortcircuit XT is in Beta!

[baconpaul]

Yeah we haven't done LFO playmodes and trigger modes yet.

We fixed a few nasty things with macros yesterday but can you let us know a bit more what you saw. What didn't refresh?

Thanks for the enthusiasm! As we suspected and hoped, the beta has found lots of holes we didn't know we had, and stepped into some we didn't think were as deep as they are. Fun stuff!

[ik_ik_ik]

Yeah we haven't done LFO playmodes and trigger modes yet.

We fixed a few nasty things with macros yesterday but can you let us know a bit more what you saw. What didn't refresh?

A couple of things.

On EDIT mode and on PARTS, GROUPS or ZONES alter e.g. Macro 1 on Part 1. Seems OK. Then on PARTS add a new Part. Part 2 appears. Part 1 still shows as selected but the Macro display resets to 0. Alter Macro 1 with Part 1 still selected. Click to Part 2 and Macro 1 resets (as expected). Click back to Part 1 and Macro 1 resets to 0 again. Similar happens on the PLAY mode. Move Macro 1 on Part 1. Click to select Part 2. Click to select Part 1 and Macro 1 resets to 0 again. Basically seems to reset the Macros when you click to select a Part. Also, might only happen when the Parts are empty, if there is or has been a working Zone then I think it might be behaving better so maybe an initialisation thing somewhere.

WIth automation e.g. automating P1 Macro 1 with an LFO in Bitwig. On GROUPS | ZONES it follows the automation OK. Also OK on PLAY mode. On PARTS it doesn't and only refreshes on mouseover or mouseout. When automation has been in play the reset behaviour above, when clicking to select a Part, seems to go to some other last stored value and not 0.

This is SC XT CLAP or VST3 in Bitwig 5.3.13 on Windows. Feb 10 Nightly.

[baconpaul]

Thanks very useful. Added to https://github.com/surge-synthesizer/sh ... ssues/2245 since I suspect it is all the same or closely related thing

Edit: it was - thanks for the clear report. Fixed in next build

[ik_ik_ik]

Thanks very useful. Added to https://github.com/surge-synthesizer/sh ... ssues/2245 since I suspect it is all the same or closely related thing

Edit: it was - thanks for the clear report. Fixed in next build

Great! Saw the commit on GitHub. Interesting.

[Andreya_Autumn]

Heads up folks we just merged a change to how things work, if you're using MPE controllers or a Lumatone or something, you'll notice some changes.

It used to be that each individual part in a multi could be in MPE mode, channel/octave mode, regular Omni mode, or single midi channel.
We figured out eventually that while single-channel-per-part is important for multitimbral situations, the ability to have some parts be MPE and others regular Omni didn't seem so useful. Plus it made it annoying to layer MPE parts since you had to set MPE on all of them.

Starting with the next nightly (should be up within the hour) we have instead made it so parts can either be single channel or they can be in an Omni mode, and which of the three styles of Omni (regular, MPE, channel/8ve) is determined globally for the instance with a switch in the header bar. This makes it faster to switch the whole thing between MPE and regular for example. We hope/think that noone formed a very strong attachment to the way it used to work in the last 10 days of Beta. If we're wrong, let us know.

Anyway, we got a *lot* of super useful feedback in the last week and a half or so. And if you downloaded the beta build shortly after we released it, we highly recommend you update now! Many workflow details have been improved (and more improvements will come).

Thanks everyone!

[Tj Shredder]

This sounds reasonable. I never need that multitimbrality and always want MPE. My last non-MPE controller is history for a long time…
Multitimbral instruments made sense in the last millenium and mainly for hardware synths. If I want that in a DAW context its so easy to to just load another instance…

[EvilDragon]

Well, that locks your layers/splits to just that DAW then. When you have it in a multi, then it's portable between DAWs and can be shared with others.

[Tj Shredder]

A Layer is too much bound to personal taste to even want to explore other multis. And to create one need rather seconds than minutes…

[EvilDragon]

I guess you could say that. On the other hand, Omnisphere exists and does a LOT of layering almost everyone loves.

[Andreya_Autumn]

Yeah personally am 100% sure that I will never use the multi features, but I understand that there are people who feel differently. Trying to cater to both workflows is one of the design challenges we've discussed at great length in the dev team. Hopefully we've managed/will manage to make it work smoothly enough for both cases.


Anyway, we noticed today in testing that the following might need some clarification: There are two steps you need to take to enable MPE, choose MPE as your Omni behavior (in the header), and make sure all your parts are using the omni mode (in the parts tab). If you aren't getting MPE to work make sure you have done the latter also. We are going to try to make this a bit more self-explanatory somehow.

[audiojunkie]

I guess you could say that. On the other hand, Omnisphere exists and does a LOT of layering almost everyone loves.

I personally love layering.

[baconpaul]

Loads and loads of great bug reports and subsequent fixes last week. If you are running a pre-valentines day (Feb 14) short circuit strongly recommend you update.

https://github.com/surge-synthesizer/sh ... nt-Updates

There's the full first two weeks change log.

[Weasel-Boy]

I downloaded your latest build to check it out. This may have already been mentioned and if so I apologize.

On M1 Mac in Cubase 15, I dragged a sample into the default key range view. I was pleased to see my sample could be positioned where I wanted it in the key range and I could set the range spread before releasing the mouse click.

Unfortunately, once dropped, the sample expanded to the full range of the keyboard… necessitating a manual resizing.

[EvilDragon]

One of the possible end results of the drop is a full spread zone, if your mouse was closer to the top of the mapping area. This is expected (and also the same as in Kontakt and elsewhere).

[Weasel-Boy]

One of the possible end results of the drop is a full spread zone, if your mouse was closer to the top of the mapping area. This is expected (and also the same as in Kontakt and elsewhere).

No...that's not it. I've discovered a number of drag n drop behaviors that seem to be sample data related.

Besides what I previously described, I have some samples (.aif) that no matter where I drop or how wide the drop is to be, drop into a different target area and are only one key wide.

I have others that behave exactly as expected. placement and size are what I chose.

..and as a note..as I drag up, the sample size gets wider, down narrower. I tried dropping as near to the top as I could. There doesn't appear to be an "auto full spread" near a "top mode zone" that I can tell. If you drag all the way to the top then it does do it...because it has spread as wide as it can go.

So to recap: I get three different drag n drop behaviors.
1. Ignored spread to single note size and wrong note.
2. As expected...normal behavior
3. Ignored spread and placement to full spread size.