Oscar contributions

#1

Forum profile: @Oscar
Prefix: oscar

ctrl

Xtor control objects. This are all versions of the factory ctrl objects that can be used with the xtor preset system:

  • dial b xtor
  • dial p xtor
  • hook xtor
  • i r16 xtor
  • i r2 xtor
  • i r4 xtor
  • i r8 xtor
  • i xtor
  • i toggle xtor

delay

  • delay write kt ms:
    This is inspired by the equivalent objects from the great Philoop. I was having problems with getting them to return the right values, so I made a delay write that returns the correct milliseconds and kticks. It's useful to get exact delay times on a delay read object.

osc

  • supersquare b:
    This is almost the same than the factory supersquare oscillator, but that one didn't use the negative range; this one does.

patch

  • xtor manager:
    This is an SDCard preset manager that borrows a lot from the one from DrJustice. It only works with certain "xtorable" objects, which, although a possible nuisance, helps to avoid glitches and to have a faster, more stable performance. Supports integers and multiple preset managers for different sections.

This is all for now, I'll add more stuff later.
Any advice, request, or comment, please tell me; I'll do what I can.
Have a nice day.

#2

The xtor system is a parameter preset system that saves on the SDCard, and as such can be saved and loaded while the patch is being executed. I know the name is kind of stupid; I couldn't think of a better one that was short.

It works only with certain special objects that are "xtorable" (I know, I know how it sounds). To use it, add an xtor manager object, add some of this controls, and write the name of your xtor manager in each of the controls you want to store. You can have multiple xtor managers.

It's not for everyone, every time, sometimes the preset manager from DrJustice is a lot better because it can save all the parameters in a patch (although it cannot save integers if you want to be able to move objects positons later), and it doesn't require special objects. Use this system when:

  • You need to add and delete objects from the patch while using the same preset files
  • You need to use integers (the number spinners, radios and toggles) and move objects around
  • You can't have small glitches, dropouts or silences while saving/loading
  • You need to have multiple separate preset managers for separate parameters, even combined with other preset systems.
  • You keep having problems with the drj preset manager related to the number of parameters of your patch, or changes you've made to it. The xtor system is tolerant of changes, and more nimble because it can cache and limit the objects it controls.

I'll add some more xtorable controls later. Does someone need vertical radio controls? I'll add them if they are requested, or any other, really. Anyway, if you want to make an xtorable version of an object, it's easy:

1- Add an atribute to the object of the type objref. Name it x.
2- Add this in the Local Data section (do not delete anything else): bool registered = false;
3- Add this in the K-rate Code section (do not delete anything else):

if (!registered) {
	attr_x.registerParam(PARAM_INDEX_attr_legal_name_value, "attr_legal_name_value");
	registered = true;
}

4- Substitute both appearances of the word value in the second line with the name of the parameter you want to preset. If there are multiple parameters you need to preset in the same object, you can add the second line multiple times in the same place.

That's it. :slight_smile:

#3

Here's an example of how you can use the xtor manager with the xtor system:

It saves presets with this template: prefix000.xtor. "000" is the preset number padded with up to two zeros, so you can use from preset 000 to 999.

All the inlets are optional, but, if you need to have multiple presets, you have to pass it a preset number, and, if you need to have multiple preset managers or multiple patches in the same folder, you need to pass it a prefix. You can use the inlets or the embedded buttons to save and load presets. They all work when the button goes from 0 to 1. It displays the last preset used at the bottom.

Finally, the params attribute decides the maximum number of parameters that can be saved. Generally, you don't need to worry about it and you can set it as high as you want without performance penalties, but, if you are having memory problems, you can save a little memory by reducing it the most you can. Most of the time you shouldn't care, it caches very little data, I only added it for some very extreme cases.

Right now it doesn't have a way to control it with midi directly in the object. Should I add midi controls to it? I should, shouldn't I? Or shall I add a separate midi controller object that connects to its inlets? I don't use midi cc or program normally, so I don't know which has better usability. Maybe it should be a separate xtor manager? I wonder...

Also, it doesn't have an audio fade outlet because I haven't had any glitches or drops. It caches some of the calculations that the preset manager does and avoids some others, that's on top being able to limit the parameters saved and also being in another thread, so it's faster. Yet, if someone has problems with glitches, I'd be happy to put it. :slight_smile:

#4

I will try your Xstore System soon, looks very nice!
Thank you.

#5

No problem! Please let me know if you detect problems or oportunities to make it better.

#6

Thanks a lot for the xtor system! this allowed me to finally achieve a big polyphonic synth with ability to save and load all 40 parameters midi & analog at once, with minimum cpu/ram, it is perfect!
I didn't see such a simple & efficient preset manager before.
Do you plan to make more objects? (a counter would be my first wish :wink:)

#7

Sorry, I kinda left because I thought the Axoloti had become abandonware. But today I decided to take a peak, and I saw that there's a new prototype from the community; so I'm hopeful again.

Thank you for the appreciation; it was actually kind of easy to do: I kind of did a lot of the same things that drj does with his manager, except that, due to some bugs and missing features in the Axoloti software, his manager has to do a lot of tricks to find the objects it stores. I simply make xtorable objects report themselves with the preset manager, (that's why you have to write the name of the xtor manager in the objects) that way, the manager doesn't have to do any tricks to find them. If the issues with the Axoloti are ever solved, the other managers could be just as fast. Those issues are very easy to solve, but development seems kind of frozen right now; maybe if there's some kind of community fork later they will be solved, and my xtor system will become obsolete.

Sure, I'd be happy to make a counter, what kind of counter were you thinking of? What kind of features would you like it to have?

#8

Yes the new prototype would be very cool for all of us greedy animals. I wish I could make bigger messy patches without spending most of the time trying to make them fit with ressources.
I use very basic counters, a cycling up one is what I use mostly because I use it with a single analog switch. I wish I could save its state for presets in the xtor manager.
Maybe a up/down version could be useful for the community too.

I use a lot your hook xtor as it records position of analog pots.
There is a cool object called MultiPot 3 from @TheSlowGrowth in the library. Do you think it is possible to adapt it's scale mode to a simple hook dial? In some cases sudden changes of values can be hard in live context, the scale mode is a smart solution.
I don't know the time needed to make those, I have no skill for coding so nevermind if it's too much work, Anyway I think this xtor deserves to be more known in the community for people who wish to design sounds without screen and mouse!

#9

hi oscar,

interested to try the preset system. i cant find any of your objects in the library strangly. can you let me know how i can find them?

#10

Hi. Sorry for not answering before. Life and health got in the way.

:slight_smile: Hey, that's the main use i give to the hook control too, that's why I made a version of it that can be used with xtor. Hum. The way I understand it, the scale mode makes it so that the potentiometer changes are applied as increments/decrements to the stored value, and it makes the stored value approach the potentiometer the more you move it. Am I right?

What I don't like about that is that the values are not very consistent, they depend on where your stored value was with respect to the pot value, how fast you change it and how many times you move the pot back and forth. What do you think? is it a real problem? I think the scale mode is actually very useful for some things, but I'm not sure if it solves this issue well enough. I'm finding this solution can cause a lot of inconsistency. Also, there's a problem with hook dials that are used with presets, because they would still jump.

To be honest, most of the time I solve the problem with a blue low pass filter before my blue inputs, but it's not the most intuitive solution and it doesn't give the level of of control I would like to have sometimes.

I've been wanting to create an object dedicated to manage presets with pots for sometime. There are some things I don't like about using the hook. Sometimes you don't want to need to match your pot value with the preset value in order to change the output. Most of the time I want pots to behave like the pots from digital stomp boards, where they are used instead of the preset value after moving a little. I implemented something like this sometime ago, before the xtor thing, using a table and pre-existing objects. Other times, I've just modified the hook object to always be hooked, though it doesn't work well with noisy pots. I'm thinking it wouldn't be hard to implement it well as a dedicated object.

To be honest, this object it probably wouldn't even need the xtor system, it doesn't need control dials, it only needs display dials; but I think it still would be nice to have control dials to easily be able to play with the patch in the computer or with a midi controller or a mod-source. Also, I already have the xtor system made, and it's nice to be able store different kinds of control data in the same place. So I think I can do that, and it is relatively easy.

Maybe I could add some elasticity parameter to an object like this. It could smooth output values either by approaching them at a fixed speed or with some kind of spring-like behavior that is faster the more it has to change. I could also add a parameter to define how much an input value has to change before it takes over. Would that solve your issue? What do you think? Also, if you think that kind smoothing would solve this, do you think it would be better as a separate object? Or would you prefer it integrated to the pot manager object?

#11

Hello, Moutcast.

Uh, that's weird. Could you post a screen-shot of the community folder hierarchy inside the panel for creating new objects?

The objects should be under the folder named Oscar. The manager is under the patch folder and the other objects are under ctrl.

#12

hi oscar, thanks a lot for the answer. i found them already and u i am using them.

great work thanks a lot.

greetings jens

#13

Hi, thanks for all these great thoughts & ideas.
I guess there are as many uses of pots and applications for it, as people's feeling to use them a way or another.
In my experience, for some kind of modulations, I can't really predict where is the hook position of the saved preset, until I reach it. And if it is on the opposite side of the pot, i'll turn thinking maybe it's here? or here? or here?...This can happen in 1 second or 3 seconds if I missed it and rolled back the knob before hook. In any case it ends being little cause of stress in live situations, I shouldn't have to focus too much on it.
So yes sometimes I wish the parameter could change directly at first move. More radical changes in sound, but reactivity...
It might be a very good option with elasticity, because by hand we might have flexibility to catch and extand the action in sound, more musical feel and result maybe.
And the range parameter to take over is a very good idea too, though It should be adjustable, or make tests to find the sweet spot for range?
So for me, according to different uses I can imagine, the best would be:
- a direct change hook version, with the same deadband size option as MultiPot 3 for noisy analog pots. is that possible?
- an elastic version with choice to activate or not the range parameter, and speed modes for changes. (linear / spring)
Those into the xtor system would be great, and separate the two options for ressources purpose: not being obliged to use complex object for simple task.
But maybe it doesn't take much? I have no clue about that.

Those with the existing simple hook xtor, we may have great comfort with choices.

...And way more important, I wish you good health!
:slight_smile:

#14

Thank you, cire. Okay, so here's what I'm thinking, kind of a road map:

1: Some kind of magnetic hook, where the dial hooks itself to the input after the input changes a certain amount. It has a blue input, a blue output, and also has two dial parameters. One of the dial parameters is called main and the other is called minDelta (I would accept better names if someone has a suggestion). The main parameter defines the output, and the minDelta defines how much the input has to change so that the main dial copies the input and is hooked to it. The minDelta might be also an input.

There can be a version of this object for the xtor system and another that just writes and reads its value to a table, then people can store that table in the sd card however they like. I'm already working on this, and I think I'll have something to share soon. I'm not sure about the name though. PotManager? PotMan? PotHook? HookPot? PotPusher? PushPot? InputToParam? Any ideas? I'd also make versions to manage different number of potentiometers.

2: Then I'd make some objects to smooth the output of the potManager output. I think you're right they should be separated; another reason to do it that way is that they can be used for other stuff. I was looking at some old patches, and then at the library, and I saw that there are actually more objects apart from a lowpass filter than can be used for this. There's a smooth object, a glide object, and many variations. I'd still like to add some other options. I'd like to add some objects that interpolate between two values, so I can add an output to the potManager that gives the last unhooked value and interpolate between it and the main output. That way, there's only interpolation when it goes from a preset value to an input value.

Some of the smoothing options that I'd like to add, the options I'd like the most, also interpolate from the unhooked to the hooked value, but with a fixed duration, so no matter how much the input changes, the interpolation has the same duration. They require a very intimate integration with the manager though (the connections would be too complicated otherwise), so either they are added to the interface of the potManager or I add a version of the potManager with a text field where you write the name of an interpolator object. I'd like to make this kind of interpolation option first and then others.

3: A hook with a deadband scale function. To be honest, I couldn't exactly get how the multipot stuff works; I get what it does, but its exact way of doing it is kind of hard to deduce because the values it gives can change a lot depending on the speed of the input change. I was also too lazy to deduce it from the code because there's a lot more stuff in there, it has few comments and the axoloti code editor is not the best for understanding code written by others. I myself should put more comments in my objects too, now I realize.

Anyway, I might just try to copy from it and make it xtorable without the other modes, and if for some reason that doesn't work, then I'd make my own deadband scale algorithm; although it's a lot more probable that I finish it if the first think works, because, honestly, I'm not too excited to do the second thing. I think the first think will probably work.

4: Probably I didn't do all the objects I could do in the second step. There are many ways to do them, and most of them are easy to code. Also, I probably got bored after doing some of them and jumped to the third step.

What do you think about this? Any suggestions would be appreciated.

#15

Hello Oscar,
I’m travelling for a Few weeks so i am not very active with axoloti, sorry for long delay.
Thank you for this plan it looks very Good to me.
Potmanager or potman, is nice name and easy to remember with its function.
Mindelta sounds cool, alternative could be React.
I don't really have more to say, everything is very promising.
Maybe @mtyas would have good ideas about all that?

#16

Hey @Oscar, I really liked your idea for a potentiometer hook and tried implementing one myself. It looks promising in allowing me to use 1 pot for several different effects and not have jolts when switching between effects.

here is a little demo:
dial-freezer.axp (3.3 KB)

#17

hi @Oscar

i have a patch that needs 86 parameters to be saved and recalled. i made some custom xtor objects as well for this patch. unfortunately not all parameters are loaded/saved when i hit save or load, some get even wrong values back. would it be too much asked if i sent you a WeTransfer link of the patch and you could have a look? or are there any debugging options i can enable? do the xtor objects have to be saved as objects before they work (currently some are simply embedded in the patch)