Improvements/Wishes for the patcher

#310

thats is the point....the midi range (0...127) is bound to the whole range on other types e.g. -64..64, 0..64

if we did this for const/i it would bind from 0...(2^32)-1 which is not what you want, you want to bind to 0...127 i.e. a limited part of the range which would not be consistent with other type mapping.

for this to work, const/i would need to have some kind of bound range, so you could say min=0/max=127.

often this is the reason things are not done, because to do them 'properly' requires more changes than it may appear to someone not familiar with the code... not because the request is being ignored/dismissed.

#311

Thanks @thetechnobear

Yes, as I mentioned I know the limits of midi 0-127. Personally that would be a fine object for me. I use the ctrl/i for everything and in most cases I never exceed values above 0-127. Like for muxers, demuxers etc..... I dont think a lot of people use muxers with 128 inputs so I would say in majority of cases 0-127 would be enough.

But one could still have a ctrl/i.. for the huge ranges... And add a new one, which stays with in midi range 0-127, like ctrl/i cc ..... To give some more control over that object.

And I know some changes are being made, so I just hoping that this is a thing that would be taken into consideration when making the changes :wink:

See it as a friendly reminder :slight_smile:

#312

yeah, when I get back to looking at the (new) code soon , I'll take another look.
certainly the new parameters system has more meta data, so it should now know the min/max that is specified in the parameters type. if so then it can scale using that information.

this would still mean we'd need to create a const/i 7bit to have this limit imposed on it... or users can create their own object with min/max on it...
e.g. if you want 0..4, then this would be split over the 0...127 range, rather than a dumb usage of using 0...4 midi which on many CC pots would be 'fiddly' and create a dumb dead range past 4..
as I said the 'use case' is wider than merely allowing 0..127 CC on const/i

#313

Sounds interesting with new parameter approach and how scaling would work :slight_smile:

#314

"New Object" window - please make resizable. On 27" display - its a pain to view on small window with part of text, part of big-panel device.. Uncomfortable!

#315

I think this also have been up several times before, but would be super awesome to be able to read the size of a raw/wave files in samples, so the tablesize is set automatically, according to the actual loaded audio sample. Like "-read resize" does in PD.

This is simply a must when working with tables and audio in general and should be implemented into Axoloti. It would make working with audio much simpler and much more fun too :slight_smile:

#316

i think the fixed type table sizes (power of 2?) are there because you can optimise the code quite a bit this way...

#317

Yes, I dont mind having fixed tablesizes like that. But lets say you set the table size to 262144 samples... And then load a sample that is 134333 sample long. There there could still be some kind of compensation internally, that first detects the length of the sample and then automatically sets a limit within the 262144 fixed samplesize to 134333 samples. This way you still keep the fixed table sizes, but Axoloti automatically detects the sample size and compensates for it within the fixed table size.

But the trick is getting the size of the sample loaded. That information is essential and can be used for many things and it can still be used even though the table sizes are fixed.

#318

@lokki is correct, it's the access code that is optimized, taking advantage of the end of the table = 64 which is also a power of 2.
That's not to say you can't easily create a variation where you lose this optimization, particularly if you access by int index rather than 0..100%(0..64)
( which also has its advantages which you lose)

... I suspect someone has already done this in the community library given its simplicity.

#319

@thetechnobear

As I said in my second post to Lokki, fixed table sizes are okay, that is not the main issue. The main issue is being able to read out the size of the file loaded into the table. Then one can automatically set compensation using a dial or whatever:

Would be super nice to be able to do this on patch start up:
1. Read out samples file length
2. Calculate what to set on a dial, from the samples length
3. set the math on the dial.
4. Play your sample happily at the right pitch and time.

This can easily be done and I dont mind patching it manually. If we could just get that sample length it woud make many things easier. And I don't think there are any objects that does this in the com.lib. if you know of one I would love to see it.

If it is a simple thing to do, it would be a lovely update :wink:

#320

To those who might also be interested in my last wish on the list, reading out a raw files length in samples, @DrJustice was kind enough to create that object.

Look for:
drj/file/file_size

Thank @DrJustice :slight_smile:

#321

Apologies if this has already been covered, but I think the ability to create custom port types would be really really useful.

@lokki and I are working on a set of objects that require the connection of many parameters in order for them to work.

@lokki hit on the idea of using red Audio Buffer ports to roll all the parameters into one multiplexed signal, using each of the 16 items in the buffer array to hold one parameter.

This is great, but, obviously, it's not audio data, and connecting the output of one of our objects to an audio output will produce a painful blast of noise, or at least nothing useful.

It would be great to be able to define a custom array type, and have ports of that type only be able to be connected to other ports of the same type. That way, you can save time for your users, patching up lots of ports, by multiplexing several parameters, but avoid the issue of eg ports meant to carry non-audio data being accidentally connected to audio outputs.

I'd envisage being able to:

  • Choose any existing data-type/representation for the port (so avoiding the issues associated with allowing arbitrary port types)
  • Choose a colour for the ports
  • Choose whether the port should be allowed to be connected to ports of other types

Cables connecting custom ports could be visually distinguished by eg being striped.

a|x

#322

Hej!. the keyboard object could be like the [key] object in puredata. No inlets and just an ascii output. then using [== ], one can use the keys to control whatever.
A more sofisticated version could be one with a qwerty to midi notes converter like ableton live/ fasttracker does but that functionality will just pop up automatically in the forum as soon as there is a 'keyboard' object, i think.. :wink:.

Regarding wishes for the patcher.. I wish that it was possible to segment the subpatches at 8 or 12 knobs.. so "big" objects with more than 16 knobs don't look so long (in my screen sometimes I even have to scroll down to access lower parameters). But I'm aware about what that change could mess up.... I wish I knew enough to try myself to work in the Gui..
greetings
S