Text String Display

#1

I think the answer is currently 'no', but wondering if it's possible to display a thing in the Axoloti application, either as a Display on an object, or using a dedicated string-display object?

a|x

#2

It should be possible, but there is currently no such object. There is an object to display the hex value of a string, but it's not that useful for regular users.

Some objects to concatenate strings/values would be handy as well.

#3

Thought as much. The hex disp object is pretty handy when developing custom objects.

a|x

#4

Displaying strings is best done by printing to the log window rather than showing them in an object. I thought I had published an object for this, but I can't find it...
The trouble is that strings can be any length, they don't fit well unless it's only to monitor the first 16 characters or something.

The hex value shown is actually the location in memory, not a hex value of some characters.

So far the only use case for string processing is generating filenames on the fly, and I believe the current limited object set serves that purpose, although you need to rename files to follow axoloti if you want to use a set of files.
More advanced string processing would need a deep revision, and also are a potential cause of trouble, like recursive expansions generating overflows. I don't plan to put effort into the development of more string processing objects any soon, sorry.

#5

Fair enough.
For the record, my use-case was quite specific. I'm working on a phoneme synthesiser object, and I wanted the name of the phoneme to be displayed on the object, when it was selected. It's not a big deal if it's not possible, though.

One thing that might be handy though, is a combobox parameter type, so parameters with string references can be changed at runtime. Currently, I have to either create an attribute (can't be changed at runtime), or use a knob or integer param, with no text to show what you're selecting.

Or, thinking about it, how about the ability for an object to create it's own mapping, to display text values when a rotary control is adjusted, like the existing mappings for pitch, etc.?

Probably a feature-request.

a|x

#6

Might have a go at basic string functions myself, as I need something to display some values on the lkm1638 module of the synth I'm building.

#7

seems to me there are two use cases

a) real string processing
as @johannes says processing strings is dangerous and expensive, it seem the only 'unavoidable' use case for this is filenames. (and even this I would question that we could perhaps do better with 'file indexing')

a) user display
this I can see a really strong case for, and as such we already do in some places.
this is actually where the underlying data is held as an int, but the display to the user is text.
i.e. there is a translation function.
I think the user case presented here, is we need these to be user definable e.g. so we can have 'filter type' which is represented as 0,1,3 but displayed to the user as "LP", "HP", "BP"

BUT this then is a much 'bigger topic' as its gets into being allowed to translate an underlying data, into a user form. e.g. int32 into Hz or BPM ( which as I say, we already have in places)

this also raises the 'ugly' question of where does this happen?

currently, this is often done in the java UI... this makes sense as you want to be broadcasting the minimum about of data and then interpret.

BUT this is a 'bad solution' when we start writing alternative controllers, as they wont use java, so we have to write all the mapping code again, it makes 'user defined' mappings hard, since they have to be in the java app (this means potentially custom user classes for the app, something we discussed in the 'custom ui thread'

finally the it makes it tricky for users to define nice simple mappings.. e.g. a table indexing values , since ideally these are stored as static strings which in firmware can be supplied for rendering for other controllers.

I really therefore see it, as part of the future of more definable user interfaces, and also the development work that needs to go on for parameters.

I guess a stop gap solution, would be a selectable combobox, thats stores its string values in a table, and outputs a int.
allowing the user to define strings at patch build time, and select at runtime - so there is no string handling at runtime/in the firmware.

it could also have an int input, to allow the entry to be selected programmatically
its only a stop gap, since Im not sure how this can be put into the parameters, and given they need a refactor anyway, perhaps not a good time to put it in there.

Im not sure if this covers @toneburst requirement fully or not, it only covers known strings, and certainly not dynamic strings.

#8

Personally, I'd be happy with just being able to display a few characters of text at the bottom of an object, and in a combobox that can be tweaked at runtime.

Having said that, I can see more comprehensive char support will be really useful once a display is connected.

a|x

#9

I fear such effort will be frustrating for both of us. Full text processing requires dynamic memory allocation, reference counting, garbage collection, and even when all these things are implemented, it would not be hard real time, potentially causing memory overflow during patch execution, and ultimately text processing does really not belong inside the dsp workload.

My primary concern here is avoiding code duplication. If objects would start to define their own way of representing values and conversions into text, we 'd get a lot of duplicate code for each object in a patch that uses the same representation/conversion. The java gui is not so constrained, but the patch binary code size is. Not a problem for a singular object - for instance one managing a physical UI dedicated to step sequencing, but for general pitch/time/frequency parameters this is a concern.