Forums > Jitter

New revision of a FreeFrame plugin has problems

April 26, 2007 | 9:38 pm

I’ve been working with Alex, the guy who runs the (down at the moment) site BigFug.com. He’s written a manyFreeFrame plugins and I’ve been using one, Luma3D, for a piece in an upcoming gallery show. The plugin places each pixel in a feux-3D space based on how bright it is. The brighter the pixel, the further outward it appears.

Through communications he was nice enough to throw together a new version of the plugin to address some bugs. The problem is with the new version only the top 1/4 of the screen is being rendered. I’m probably going to have to use the old version, but I want the new one because it looks better and renders faster.

I’m attaching both the old (luma3d.dll) and new (fugluma3d.dll) to see if anyone out there can confirm or deny my situation. In one of our conversations he noted:

- [The new version] now uses processFrame() rather than processFrameCopy()

Would this change be resulting in the problems I’m experiencing?


April 26, 2007 | 9:45 pm

I might be able to briefly check this tomorrow. However, I’m a little
confused about how a spatial effect could use processFrame().
Presuming that the plugin works like I think it does (it sounds a
little bit like jit.plume), he’d be drawing pixels into the part of
the image which hasn’t yet been analyzed. Unless he’s using an
internal image buffer, which he might be.

In any case, I can take a quick look tomorrow.

jb

Am 26.04.2007 um 23:38 schrieb Jake Mauer:

> I’ve been working with Alex, the guy who runs the (down at the
> moment) site BigFug.com. He’s written a manyFreeFrame plugins and
> I’ve been using one, Luma3D, for a piece in an upcoming gallery
> show. The plugin places each pixel in a feux-3D space based on how
> bright it is. The brighter the pixel, the further outward it appears.
>
> Through communications he was nice enough to throw together a new
> version of the plugin to address some bugs. The problem is with the
> new version only the top 1/4 of the screen is being rendered. I’m
> probably going to have to use the old version, but I want the new
> one because it looks better and renders faster.
>
> I’m attaching both the old (luma3d.dll) and new (fugluma3d.dll) to
> see if anyone out there can confirm or deny my situation. In one of
> our conversations he noted:
>
> – [The new version] now uses processFrame() rather than
> processFrameCopy()
>
> Would this change be resulting in the problems I’m experiencing?


April 27, 2007 | 1:49 am

This same behavior occurs in a variety of plugins across various developers plugin sets. I mailed support about it once, and have mentioned it before. I’d be very happy if you could discover the cause, since I have many commercial plugins that I’ve paid for that I can’t use in jitter because of this.


April 27, 2007 | 3:32 am

Well the answer has to be somewhere in the changes he’s made because the old one works. I emailed him today and I’ll give him the link to this conversation, I think he’s been active on these boards before so he may even chime in. Either way I’ll keep the thread updated. And Jeremy thanks for taking time to look into the situation.


May 3, 2007 | 11:25 am

Thanks for your report. I’ve released new versions of jit.freeframe
on the Incremental Updates page, which should correct problems with
in-place processing on all platforms:

http://www.cycling74.com/twiki/bin/view/IncrementalDownloads/WebHome

jb

Am 26.04.2007 um 23:38 schrieb Jake Mauer:

> I’ve been working with Alex, the guy who runs the (down at the
> moment) site BigFug.com. He’s written a manyFreeFrame plugins and
> I’ve been using one, Luma3D, for a piece in an upcoming gallery
> show. The plugin places each pixel in a feux-3D space based on how
> bright it is. The brighter the pixel, the further outward it appears.
>
> Through communications he was nice enough to throw together a new
> version of the plugin to address some bugs. The problem is with the
> new version only the top 1/4 of the screen is being rendered. I’m
> probably going to have to use the old version, but I want the new
> one because it looks better and renders faster.
>
> I’m attaching both the old (luma3d.dll) and new (fugluma3d.dll) to
> see if anyone out there can confirm or deny my situation. In one of
> our conversations he noted:
>
> – [The new version] now uses processFrame() rather than
> processFrameCopy()
>
> Would this change be resulting in the problems I’m experiencing?
>
>
>
>


May 3, 2007 | 8:18 pm

Thanks Jeremy, it fixed my issue! I’m interested to hear if it helps others that have been having problems.


May 4, 2007 | 5:24 pm

That absolutely was the problem, and I thank Mr. Bernstein for his efforts.
For Mac peoples interested in more freeframe availability, I highly recommend communicating with the developers. Many of them are only reluctant to port due to perceived lack of interest.


May 7, 2007 | 10:42 am

Am 04.05.2007 um 19:24 schrieb Leo Mayberry:

> That absolutely was the problem, and I thank Mr. Bernstein for his
> efforts.

You’re welcome, but please call me Jeremy.

jb


May 7, 2007 | 1:36 pm

unless you’re bitching about pattr again, in which case he’s mr.
bernstein again. :P

On May 7, 2007, at 6:42 AM, Jeremy Bernstein wrote:

>
> Am 04.05.2007 um 19:24 schrieb Leo Mayberry:
>
>> That absolutely was the problem, and I thank Mr. Bernstein for his
>> efforts.
>
> You’re welcome, but please call me Jeremy.
>
> jb
>
>


Viewing 9 posts - 1 through 9 (of 9 total)