rorywalsh/cabbage

prefix() / postfix() don't appear to work in imported widget xml

Closed this issue ยท 17 comments

Since the changes involved in: #69

It seems like imported xml widgets only get the channel values in the popup, and aren't getting new formatting from prefix() and postfix().

Can you provide a minimal xml file for testing? I've never used plants so not quite sure how they work or where the XML file comes in.

Sure, thanks for taking a look!

These are "two parters"... so here's the main .csd:

<Cabbage>
form caption("Example") size(300, 180), import("ImportExample.xml"), pluginid("xmpl")
Widgets pos(30, 30) size(50, 50), channel("Import1"), namespace("Widgets")
rslider pos(30,100), size(50,50) channel("Knob2"), prefix("Prefix Test: "), postfix(" Postfix Test.")

</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
nchnls = 2
0dbfs = 1

instr 1
	ExampleUDO "Import1"
endin

</CsInstruments>
<CsScore>
i1 0 z
</CsScore>
</CsoundSynthesizer>

And here is the xml widget file it imports:

<?xml version="1.0" encoding="UTF-8"?>
<plant>
<namespace>Widgets</namespace>
<name>Widgets</name>
<cabbagecode>
	image bounds(0,0,50,50) colour(0, 0, 0,0) {
		rslider pos(0,0), size(50,50) channel("Knob"), prefix("Prefix Test: "), postfix(" Postfix Test.")
	}
</cabbagecode>
<csoundcode>

opcode ExampleUDO,0,S
	SChanPrefix xin
	kKnobValue chnget strcat(SChanPrefix,"Knob")

	printk2 kKnobValue
endop

</csoundcode>
<help>
  Example to show popup prefix and postfix in imported plants
</help>
</plant>

I can take a look at this. The custom plant import stuff is a little cryptic.

Your example code now works fine in the latest dev tip. You can grab a new build shortly from Azure. Let me know if it passes your tests and we can close this out.

Awesome, thanks Rory! Will freshen my build and test again once the build finishes.

This mostly looks fixed, however newline characters aren't rendering in the imported widget popups for me. Hopefully an easy fix?

Also there seems to be some weirdness with rslider valuetextboxes getting the popup prefix and postfix text, but still no actual popup? This is unrelated and probably deserves it's own bug... but I just noticed it and am pretty sure it's new within the last week.

As mentioned in the other thread too, very slow and laggy build. Hopefully debug code left enabled. :)

Thanks I'll take a look. I don't know what might be causing the slowness in this build. I haven't left in any debugging stuff. I'll take a look. Can you file a new issue about the other problem?

Ha, looks like @rorywalsh and I were doing double duty! I noticed the newline issue when I was attempting to fix this. It might require a redesign of how the escaped and stripped prefixes are generated. Right now, when the prefix (or postfix) identifier is encountered, the contents are stripped of escape characters and saved back to prefix, while a properly escaped version is saved to prefix_escaped. However, from what I can tell Cabbage code in plants is parsed multiple times; after the first time, prefix doesn't contain any escape characters anymore and so neither will prefix_escaped. Let me think about this some more.

On a related note, I wonder if I should clarify the intent of the prefix and postfix identifiers better in the manual. I wrote them to be able to format parameter values (specifically in hosts to make them look nicer and more in line with commercial plugins). It makes sense to me that this formatting should apply wherever values are displayed, e.g. popups or textboxes. However, my concern is that people will start using them as labels instead of value formatters (e.g. prefix("Mod Freq: ")), which would look exceedingly weird in hosts.

So contrary to what I originally suggested, maybe it actually does make sense to keep popupprefix and popuppostfix around so people can apply different formatting for the specific case of popup bubbles? It would also alleviate the need to allow escape characters in prefix and postfix since I can't think of any other place that would need them.

(FYI, not noticing any build slowness on my end)

Hi @awelex, I think you might be right about these identifiers getting abused, and used for things they shouldn't really be used for at all. And Cabbage has a long line of users who love to do just this! ๐Ÿ˜†

Should we perhaps use different names for your new identifier then to avoid confusion? What about hostprefix/hostpostfix?

Btw, no work doubling here, I didn't have a chance to look into this any further!

Yes, a better identifier might be a good idea. I can see two scenarios:

  1. hostprefix, as you suggested. In that case, it would make sense for these prefixes and postfixes to only show up in the host and nowhere else (i.e. not in the plugin GUI).
  2. valueprefix: these would show up in the host and wherever the plugin GUI displays values (e.g. value textboxes).

In both cases, they would now longer accept escape characters. With regards to popup bubbles, it could be as simple as popupprefix taking priority over the new identifier -- if it exists, it is used instead of the new prefix identifier.

My vote would be for 2) as I think being able to display units on textboxes would be a nice touch.

Either way, once we decide which way to go I'd be happy to make the changes in a PR.

As this is something both yourself and @tgrey1 will most likely end up using more than I, I'm happy to go with whatever you decide ๐Ÿ‘

I'm going to restate your idea just to make sure I properly understand what you're suggesting:

  • valueprefix() would be meant to be used as a short prefix that's attached to the value, and renders both in the host and in the gui.
  • popupprefix() is ok to be used more like a longer tooltip suggestion, only shows up in the gui, and takes precedence to render in the gui if both are set.

Like Rory, I will also defer opinion since almost all of my work lately has been in cabbage as the host, not exporting to DAWs (yet, that will hopefully start changing soon)... but this sounds ok to me.

Re: the lag

Can you try running the SimpleADSR.csd/adsr.xml combo posted in this reply:
https://forum.cabbageaudio.com/t/graphical-presentation-of-an-envelope/1840/7?u=t_grey

It used to run pretty smooth for me, but now the redrawing of the table is incredibly laggy. I am starting to suspect it's something else unrelated on my system tho... I've tried stepping back both cabbage and csound, and neither seem to help.

Hi @tgrey1 I see this slowdown myself now. I'll take a look. I've no idea what is behind it. It seems to be relatively new. Older builds don't show the same problem. FWIW, the issue can also be seen in the SimpleTable example that's accessible from the Cabbage->Examples->Misc menu.

Awesome, thanks! At the very least I'm glad I'm not crazy... I don't know how I haven't noticed this issue before, since so many of my instruments use similar redrawing methods.

I'll create a new issue for tracking and discussion there if needed so this doesn't get further thread-jacked. :)

I'm going to close this now as I believe @awelex has addressed this issue, and the slow down in performance of gentables.