String printer to k3d file path

blackburst's picture

I'm trying to switch 3d objects that a k3d object loader loads by sending the file paths with a bunch of string printers into a string multiplexer, then into the file input of the loader. No joy. Strange thing is that if I copy the string from the printer and put it in the loader it works. any ideas?

cybero's picture
Re: String printer to k3d file path

The attached file .qtz + models works for me. Based upon Gravity Bunny and using the bunny and Corbu.3ds files.

Does it work for you?

I might add, this does not utilise a String Printer patch.

I didn't find it to be necessary in this construct.

PreviewAttachmentSize
swapmodelsKineme3D.zip267.82 KB
ReadMe.txt1 KB

blackburst's picture
Re: String printer to k3d file path

Thanks cybero, yours works so i guess you can't send file paths with string printers?

cybero's picture
Re: String printer to k3d file path

Quote:
i guess you can't send file paths with string printers?

Not so much a matter of can't,blackburst, more a matter of why go to all that effort when much simpler solutions are sufficient.

One could make a JavaScript list of file paths for assets to be loaded.

One could use XML Importer for a similar list, but in XML format.

Similarly, Directory Importer can also be employed to such a purpose.

I find String Printer to be good for other purposes, say taking changing values, variables and putting them to an Image with String patch for display in an HCI setup, or to provide textual input to some other form of presentation.

blackburst's picture
Re: String printer to k3d file path

Sure there's better ways. But yeah. You can't.

gtoledo3's picture
Re: String printer to k3d file path

Better question.... why would you use string printer? It basically concatenates (joins) strings together. If you already have your file paths in string form (I don't see how they wouldn't be), it can plug directly in.

A few other points - if you use Directory Scanner, or Directory Scanner(Blocking) make sure that you disable the scan input after your directory has been scanned. Otherwise, the whole composition will run slower, because it will constantly be scanning the folder to see if it's updated. You probably don't need that (but that's what that function will do). So, enable the scan, disable it, and the output will hold the last structure without scanning the folder every cycle.

If you know what the file paths are, the way to handle loading file paths with the most performance is to store every file path in the input of a string multiplexer (eg. "hard coded), or slightly less good - in string input splitters, that then goes to the multiplexer. Javascript is OK for doing this as well, but depending on the OS version, and whatever is going on in javascriptcore at the moment, the composition could become unweildy, unstable, or crash, depending on the script and especially- the amount of input/output ports.

cybero's picture
Re: String printer to k3d file path

Well, it certainly isn't a matter of you, I or anyone else not being able to employ a String Printer patch for such a purpose, more a matter of why employ a String Printer patch to give you your file paths [unless you are wanting to avoid hard coding the paths and wanting to make a composition that you can re-use with an entirely different set of models - thus making something of a .qtz utility].

cybero's picture
Re: String printer to k3d file path

Quote:
Better question.... why would you use string printer?

LOL.

With you on that - see my earlier responses - precisely what I've been wondering about :-)

blackburst's picture
Re: String printer to k3d file path

George: Do input splitters really affect performance, and how do you measure this? Given that I'm using metric shitloads of them to get into vdmx, I'd like to know. Cybero: "Well, it certainly isn't a matter of you, I or anyone else not being able to employ a String Printer patch for such a purpose," Well yeah it is, because you can't. Even if you never wanted to, something that should work in theory doesn't. Just saying. If you chose to do it for whatever reason it won't work. In my case, I wanted to publish the second argument to vdmx for model filenames so a text input could be say (/path/etc)-enter model name-(.dae) and I could load specific models with the use of for example shape name. Yes there are other, even better ways to do it, but I thought I'd share that this avenue is a broken one.

gtoledo3's picture
Re: String printer to k3d file path

blackburst wrote:
George: Do input splitters really affect performance, and how do you measure this?

Yes, to a certain extent.

Every single extra input and output port that you make in QC, tends to affect performance, it's a matter of how often, and how much.

With an input splitter, if signal is running from one object, through an input splitter, to another object, this is adding an actual other "patch" into the equation that's running every cycle of QC.

Here's what it's doing, basically...

-There's code to check if what you're attaching to the input does/doesn't match, to allow a connection. There's some stuff to make it a subclass of QCObjectPort (or is it QCPort... can't remember).

-If it's the correct type, "yay!", a connection can occur, and then the input can start getting polled for what it's value is. (This is how I made the silly QCMeshValidate patch... just checking for type, and delivering a true or false if it's of type.)

-There's a line of code that goes down to make the input equal the output.

-If you're doing data conversion (piping a number input into an index for example), some other executable code is going down to outline the rules of what typeA= what typeB.

-If the input splitter is an index splitter (or maybe some other types?), it may call up a nib, and have a whole other set of functionality that may/may not have bugs (and does in the case of labeling stuff, in certain contexts).

So, this is all sort of paltry stuff, but it's absolutely executable code, and is "doing stuff" every cycle. In some cases (like data conversion), it may actually be a really awesome and handy thing to be able to rely on splitters always rounding (or whatever). I

n other cases, the fact that they always are running and QC is always evaluating active inputs/outputs, means that they do add one more thing for QC to do. The computation required to do this stuff isn't really that big of a deal, but it sure seems like in super large compositions, every little bit that one can cut out helps, and the sheer rendering of noodles and patches gives the editor in QC a hard time (especially from SL on... well, I haven't used Lion much).

Quote:

Given that I'm using metric shitloads of them to get into vdmx, I'd like to know. Cybero: "Well, it certainly isn't a matter of you, I or anyone else not being able to employ a String Printer patch for such a purpose," Well yeah it is, because you can't. Even if you never wanted to, something that should work in theory doesn't. Just saying.

I'm not cybero, but I think what's happening (may be wrong) is that the name "string printer" suggests that you feed it a string, and it does something special to make it "be right". That's not what it does. A string is already a string. What this does is allows you to append strings together. Now, if you want to have part of your "argument" in the string printer be a folder path name, and then feed it composition names to complete the path, that will absolutely, 100% work.

Quote:
If you chose to do it for whatever reason it won't work. In my case, I wanted to publish the second argument to vdmx for model filenames so a text input could be say (/path/etc)-enter model name-(.dae) and I could load specific models with the use of for example shape name. Yes there are other, even better ways to do it, but I thought I'd share that this avenue is a broken one.

I didn't look at the sample comp you submitted with the problem (if there was one?). Yep, that's the use case that makes sense, for sure. It seems like I even posted something that did this exact thing at some point, but I can't remember... I'll try to whip something up that shows that working at some point.

If you're publishing input to root, make sure that you press "enter" after you type into a string, or it won't actually take.

blackburst's picture
Re: String printer to k3d file path

Thanks for the in-depth reply GT, any bit of "under the hood" info on quartz really helps users like myself.