#367

so i didn’t mean to blow off this use case, i seriously meant - that description could still go different ways as far as what it means exactly. the use case itself is important to me and isn’t currently served in an ideal manner.

my question is, what alterations or extensions to the mixer API would be best? (you can of course do this with JACK and customization but why not support it directly.)

in other words, where are channels summed / split / sent / &c?

one proposal:

  • in mono+fx mode:
    • ADC channel 1 would be split to inputs 1,2 of supercollider, softcut, fx.
    • outputs 1,2 of supercollider, softuct, fx would sum to DAC 1.
    • ADC 2 and DAC 2 would be summed/sent at some point in the chain = let’s say, sent before FX and summed after FX.

open questions:
would the send/return levels require additional mix parameter(s)? is there some parameter(s) that could be thusly reporpoised? hm.

a sort of random thought: maybe this mode could be accessed by a third setting of the “monitor mode” parameter, which is already kind of a set of arbitrary routings involving the ADC and DAC?

2 Likes
#368

I totally understand. And since I’ve been having issues finding time to research how I wanted this to work/get my hands dirty in how the nitty gritty would work.

But your proposal makes a lot of sense(and thank you for spending time thinking about this). A couple of thoughts on your open questions:

Could one repurpose one of the mixer parameters as an FX-blend that would go from 0% to 100% wet ext.fx?
And it would be great to just be able to activate this “mode” from the settings somehow.

Thanks again.

#369

Are there any imminent or planned changes to the norns parameter preset loading and saving infrastructure?

Specifically, I’m thinking of starting to fiddle with some kind of grid-based sequencer for timed loading of presets via params:read(filename) or something. Perhaps tacked onto a fork of mangl, so I can scrub around and perform on the arc, while having sequences change the samples under me.

Or perhaps there’s better ways to approach this? I’m trying not to burn time implementing something that may be changing as norns dev continues.

#370

it’s a little unclear to me what you wanna do, but reading params from disk in realtime doesn’t seem like a good architecture. RAM is fairly plentiful in the system, so i’d create an array of ParamSets and populate them up front.

oh, necro-answer:

yeah, doesn’t sound technically hard, but the idea of radically different routing “modes” might not be copacetic with main norns UI decisions and so on.

1 Like
#371

thanks, understood.

I’ve been enjoying mangl, mostly by finding sweet spots, and saving them as presets that I can then load while performing. However, given the limited buttons available just with norns + arc, it’s a little unweildy to jump in and out of the mangl ui and the “params ui” to load a new preset, then go back to performing.

which started me thinking of adding a simple grid based ui for 1-grid-button-push loading of presets.

which naturally led me to thinking about sequencing the loading of presets, via the grid.

so far - with the 4 sample slots of mangl - loading the presets and the audio files into the glut buffers performs 100% aok for my purposes. I’m not looking for sample-accurate, jitter-free timing here.

I think with pre-loading paramsets up front - and possibly having more glut buffers primed and ready to go - I could get better performance, but I’m not sure if that’s even necessary for what I’m imagining.

this is going to be my first actual hopefully useful to the community stab at norns scripting, and really just wanted to make sure I wasn’t entirely off base before I take a crack.

3 Likes
#372

There is something like this implemented in foulplay. (look around line 731)

#373

Cool - yes, I see that. I’ll have a tinker.

I’ve also made some headway on my related quad scrubber idea for mangl.

1 Like
#374

Has there been any talk around making system audio parameters midi-mappable? It would be nice to be able to control reverb, monitor level, etc. Right now I’m guessing you would have to add these as parameters to individual scripts and then map them to your controller, but it would be great if the midi mapping UI was available at the system level…

3 Likes
#375

yes - there’s an open ticket for this on github

1 Like
#376

param menu overhaul is my next large feature update…!

8 Likes
#377

I’d really love to see system audio parameters being midi mappable…

#378

that’s part of my current param overhaul that just began!

10 Likes
#379

Regarding the param overhaul, is it a good idea right now to deeply integrate parameters into the operation of a script or is it likely the API of setting/getting params will change? I’m looking to take advantage of the params in the meadowphysics update I’m working on to allow saving of patterns etc. But that will be quite a lot of params.

#380

nothing breaking will happen with the param update. only additions.

#381

Wonderful! Thank you!

#382

one thing you will like if you have lots of params is the ability to pack them into sub-groups (which have their own page/tree)… but this more has to do with navigating the menu system.

3 Likes
#383

That will be so good, I’ve been working on how to organize it all with various logical hacks. Largely I’ve been “this wont be edited in params, but the storage system is important”.

#384

I’m planning to add a ‘data’ param type for storing tables in paramsets (no UI, just script glue)

4 Likes
#385

ah I am also planning to add a string type with a text entry widget

#386

I was speculating elsewhere the possibility of a grid based keyboard in the style of a plank keyboard for text entry. Potentially with an inverted-t for arrow keys. Would it be of any use if I prototyped that?

1 Like