Bug #318

cuescript does not wrap symbols in quotes properly

Added by Tim Place about 10 years ago. Updated over 6 years ago.

Status:RejectedStart date:2009-09-16
Priority:LowDue date:
Assignee:Tim Place% Done:

0%

Category:-Spent time:0.50 hour
Target version:MVC for 0.6
Branch: OS:

Description

One good example is the jmod.midiin or jmod.bcf2000 modules. These have parameters which hold the name of the midi port they use -- symbols that typically have spaces in them.

Such symbols have to be wrapped in quotes in order to send to the modules, but when fetched from the modules (e.g. using the "Get State" button), they are not wrapped in the required quotes.

VirageInterpolationEditor.png (74.7 KB) Pascal Baltazar, 2009-09-16 04:47 pm


Related issues

Copied to Max - Bug #1460: cuescript does not wrap symbols in quotes properly Closed 2009-09-16

History

#1 Updated by Pascal Baltazar about 10 years ago

  • Assignee deleted (Trond Lossius)

Well, I have spent some time investigating this one, and it turns out that the culprit is the [text] object !!!

because :
- when queried to the hubs, all of these values come as symbols
(printit says : printit: received MESSAGE "Daemon Output 4" (0x17bc1db0, s_thing 0x0) with 0 argument(s):
- when pushed into the text object, and the text object opened, it shows up without quotes
- when pushed from the text object back to Jamoma, quotes have disappeared, and the previously symbol port name is now turned into a list, which is a problem...

Same problem with jmod.cueManager : until we edit the current cue (which uses "some kind" of text object), everything's fine. Once the cue content is pushed into the text object for edition, all quoted symbols are turned to lists...

So, I guess we cannot do anything for that in Jamoma...

Maybe we should send a mail to the beta-list or ask his opinion to a C'74 developper ;-)

#2 Updated by Tim Place about 10 years ago

  • Priority changed from Normal to High
  • Target version set to 0.6

Unless something dramatic has changed, C74 is "not in the text-editor business" and this will not be a high priority.

I personally have been struggling against the text editor in Max for more than 10 years and maybe it is time for Jamoma to have its own. We could optimize it for this kind of application even, maybe implementing it as a linked list of lines with a hash to important markers.

Anyway -- this is something I can envision on the Mac, but how open is Théo to figuring out an implementation on Windows? I could not even begin to help there as I have no experience with this stuff on Windows.

#3 Updated by Pascal Baltazar about 10 years ago

since what we want to store is data associated to addresses, I guess we could make a special kind of editor.... in a way close to a jit.cellblock, with the address and associated data... but maybe in a sexier way...

an example of such a thing is the "interpolation editor" in Virage, which is exactly this kind of things...
if that's of any interest, I could request a donation of this part of the code to be included in Jamoma... as it's done in juce, maybe that wouldn't be too much of a burden to port to a Max external... ???

#4 Updated by Tim Place about 10 years ago

  • Assignee set to Tim Place

Another idea is to have an object, let's call it "jcom.textfile" that operates on the data as we've been discussing -- but implements no editor. Double-clicking on the object would then launch an external such as TextMate (Mac) or E (Windows).

I think this would be easy to do.

I like the Virage UI screenshot. Right now I'm thinking of something much more generic though. The problem at hand is that the underlying storage of the data (by the text object) is problematic, and the UI is perhaps a distraction.

Though if the Virage UI were compiled as an external editor that could read and write our text files then maybe that would be interesting too?

#5 Updated by Nils Peters over 8 years ago

Hi,

Tim Place wrote:

Another idea is to have an object, let's call it "jcom.textfile" that operates on the data as we've been discussing -- but implements no editor. Double-clicking on the object would then launch an external such as TextMate (Mac) or E (Windows).

I've added a /editWith message to jmod.cueScript to edit the current cue-script with an external editor.
I hope that helps a little.

#6 Updated by Trond Lossius almost 8 years ago

  • Target version changed from 0.6 to MVC for 0.6

#7 Updated by Pascal Baltazar about 7 years ago

  • Status changed from New to Resolved
  • Priority changed from High to Low

This apparently works in 0.6 (with jcom.cue)

it maybe even works in Max6 with the new editor ???

I've set this issue to resolved. Should I close it ? or did I miss anything ?

#8 Updated by Trond Lossius over 6 years ago

  • Status changed from Resolved to Rejected

Also available in: Atom PDF