FIXED: [ 2019.36500 win10 ] Engine Comp bugs

Bugs
#1

I’m loving the Engine comp progress, with the help of some of the other posts recently I’ve managed to get it working for the first time in 36500 and the early results look promising! Going to be a game changer to be able to unlock the rest of the cpu for TouchDesigner programming.

Anyhow, I wanted to share a couple things I’ve found - in case they were not already being tackled.

I am still running the experimental as a side install, not a fully installed version, meaning I installed it with /extract. I think that might be relevant, but not sure.

  1. So, when I drop down an Engine COMP, load a TOX in some random location on my pc ( not next to touch install, and not next to my toe, that is ) and attach it to an info DAT, I see the correct path appear:

    Capture_pathError
    Capture_pathError801×599 13.9 KB

    As you can see though, it still fails with an error despite the path being correct. I’m able to fix this by moving the TOX to a folder that also contains a windows symlink to the Touch install directory. When I check the info DAT then, it shows the symlink-centric path, and also loads the TOX.

  2. Another issue I ran into while trying to recreate the above success a second time, happened when I tried to use the Engine COMP from a freshly opened instance of Touch (newproject.toe). To fix this, I saved the toe somewhere, closed, reopened, and then with the steps from #1 I was good to go again. Perhaps this fails for a similar reason #1 fails behind the scenes. Not sure.

  3. In my last test, I built a base COMP that takes in a chop input with several channels, and multiple samples. the base comp does some maths to the samples, and outputs a few channels, with the same number of samples (circled green). This works as expected with the base comp, but if I save this as a tox, and load it into the engine COMP, I get errors and incorrect output (circled red). See screen shot:

    Capture
    Capture1194×1013 93.7 KB

    I can work around this by shuffling the channels into an arrangement that is 1 sample wide, with many channels, but I imagine this is not the intended workflow for chop in/outs.

Anyways, hope some of this helps! Awesome work with this part of Touch. Very exciting stuff.

multiThreadTest.3.toe (7.8 KB)

#2

Hey - thanks for the detailed report. There’s an issue with spaces in .tox paths in the Engine COMP (fixed in the next build) - could that have been the problem in your first and second issue? Without any spaces in the .tox path it works for me here if I recreate your setup.

I can reproduce your third issue - we’re taking a look at it.

1 Like
#3

Ahh yes, I tested on my end, confirmed - you are correct! spaces in the path caused issues for me too. taking them out, and I was able to accomplish 1 and 2.

Last Q - not a bug of course, but curious, are there plans for implementation of dat in/outs for engine comp? just looking to start planning ahead, as that would be a really useful node class to offload to other cores as well for certain heavier parsing tasks etc.

4 Likes
#4

Great, thanks for confirming spaces are the problem.

yes!

1 Like
#5

Hey @bangnoise,

Should the third issue already be fixed? I’m on the latest stable (2020.22080) and still seeing the problem.

Issue: CHOP output of length > 1 is reduced to CHOP output with length 1.

Example: Base that outputs a pattern CHOP. First row is the expected result, second row is the result.

engine-comp-chop-out
engine-comp-chop-out1020×487 23.2 KB

pattern_chop.tox (318 Bytes)

Thanks for having another look!

#6

Only time-sliced CHOPs behave as expected at the moment.

#7

@manuel_mitasch - You may be able to get around the timeslicing issue by using sharedMem chops instead of chop ins/outs.

3 Likes
#8

@bangnoise: Thank you for clarifying this.
@pointshader: Great idea. Thank you. I already started to use spout for exchanging textures, but did not think about the Shared Memory CHOP.

2 Likes
#9

Old discussion I know, but everything reported here is fixed in recent 20000 and 40000 builds. If you’ve been using sharedMem CHOPs to get around the previous limitations, I’d encourage you to move to using CHOP Ins and Outs, and report any further problems you hit. Thanks!

1 Like
#10

@bangnoise It seems like chop inputs work better in general, but for non timesliced chops (like the output from a button comp) the Engine gives warnings about not receiving enough samples unless you insert a timeslice chop before the Engine Comp input.

#11

@pointshader That shouldn’t be happening. Unfortunately I can’t reproduce it here in 28110 with a very simple setup (Button COMP -> Engine COMP which has a component doing CHOP In->Math CHOP->CHOP Out). Could you provide a .tox (and or .toe) to demonstrate the problem? Thanks!

1 Like
#12

@bangnoise You’re right, I’ve been running my client’s project in 2020.27390 but I don’t see the issue in 2020.44350.

#13

@pointshader great - glad to hear it’s working.

1 Like