Mark's Blog

mark

Dear All,

Well, it's been over three weeks since my last post. I've been too busy to write. (Not just with programming, but dealing with those nasty f'ing forum spammers that are annoying us all, and trying to get Isadora running fine for a large university installation where they're running Windows 7 on their lab computers. The fun never ends ;-) )

In any case, we're getting very close to the final feature set for v2.6 and we'll be opening it up for selected beta testers first thing next week.

One long-requested feature is finished: the new "Capture Stage to Picture" actor.

It complements the existing "Capture Stage to Disk" (renamed now to "Capture Stage to Movie") and "Capture Camera to Disk." I redid the icons for all three of these actors as you ca see above. You can capture the pictures as JPG, PNG, BMP, TIF, and (single frame) GIF files. I'm sure many of you will put this to instant use.

Also, I spent some time on this:

(Designers note: this is the Comic Sans of styled Comment actor examples . It was designed to show off the new feature, so please excuse the kitsch. ;-) )

You might be of the opinion that styled text in a comment actor might not be worth spending time on. But as we move forward to create Isadora patches that help users learn, we want to be able to make really clear tutorial files inside of Isadora itself – something that the team will be working on in the coming weeks and months.

Moreover, because of this effort, I see a clear path to offer a "Styled Text Draw" actor, because I learned how I could render RTF files in these text boxes on both Mac and Windows. So this effort has broader implications than just showing different fonts. It would be a great addition to be able to not only render text, but to style it as well.

To go with this, is our own custom "Font Panel." Mostly I had to do this because Windows doesn't have a standard tool for this like Mac OS. (They have this ribbon thing, but I really hate the whole ribbon notion; it's pretty much the definition of clutter.)

You select the fonts just like you do with the popup Actor Toolbox. If you want to change the color, you click on the swatch at the bottom of the font list. Pretty standard stuff but very Isadora in it's look and feel.

Finally, we have a nice addition specifically for Windows users: integrated Spout support.

In fact, these actors are exactly the same as the Syphon Receive and Syphon Stage Output actors which we've had for a while on Mac OS. If you save a patch with these Syphon actors on Mac OS, they'll open up on Windows as Spout actors instead and vice-versa.

So that's where we're at at the moment. We're going to stop creating and start testing next week, and get this out to you as soon as we can manage.

Best Wishes,
Mark

mark

Dear All,

Just quickly: as we head for the release of v2.6, there was one feature the team had requested that I implemented on my long plane ride to Mexico City yesterday.

There is a new "Show Tagged Actors" button is at the bottom of the scene editor:

What does it do? Well, when you click it, any any actor whose name starts with a hashtag will appear in a popup menu. Choose that item and the Scene Editor will scroll directly to that actor, placing it in the top-left corner.

(In case you didn't know it, you can rename any actor by choosing Actors > Rename Actor.) The obvious use here is to tag your Background actors with a hashtag, but any actor you tag in this way will show up in the popup list.

Another quick fix: you can not only change the color of the new Background actor, but also now the Comment actor as well.

We also made it so that the only way to select Background actor is by clicking on it's title. That way, dragging a selection rectangle won't select the Background as well. Instead, if you want to move the Background and the actors on top of it, you'll need to select the actors first and then shift-click the title of the Background actor. I want to avoid a "Lock/Unlock" feature as many users won't notice it in the menu. Given that this behavior is explained in the Help view, hopefully this is a good solution.

Best Wishes,
Mark

mark

Hey all,

I hope that the warmth of summer has headed your way as it has here in Berlin. It's been a while since I've posted because I've been deep in the land of coding for the last three months as I've reworked the entire (ancient) framework upon Isadora was built. While it may not look like something special, the image below is the first patch created on a fully 64-bit Isadora.

Now, there's still a lot to do before we start extending the capabilities of Isadora 2.6 in this new build. (For instance, now I have to go an rebuild all the plugins, though I don't anticipate this taking very long.) And then of course, there will be lots and lots of testing to do.

Still, it was pretty nice after working so hard to see it boot up and basically work. ;-)

There is a lot more to come before the late September release of Isadora 3. But being able to post the image above marks a major milestone in our efforts to make you love Ms. Izzy even more.

Warmest Wishes from the Coding Desk,
Mark

RIL

Thanks Mark for all the incredible work !!

Best,

Maxi -Isadora Latin Network

bonemap

Thanks for the update.

@mark said:

September release of Isadora 3

Is there an early indication of the upgrade cost per license? Will it be similar to the v1 > v2 or perhaps that + %10? Or is it still undecided?

Best Wishes

Bonemap

mark

@bonemap said:

Is there an early indication of the upgrade cost per license? Will it be similar to the v1 > v2 or perhaps that + %10? Or is it still undecided?

I am working on the pricing structure for an internal review by the team. We should have news for you on this in the next couple of weeks.

Best Wishes,
Mark

mark

Dear Community,

So, I've got all the plugins running native under 64 bit and they seem to be working pretty well. I also got FreeFrame working under 64 bit as well.

Here's a question for anyone that cares to comment: what about numeric precision?

In the 32 bit version of Isadora, both floating point numbers and integer numbers are 32 bit as well. That gives you the following range:

32-bit Integers: -2147483648 to +214748364
32-bit Floating Point: ±1.18×10⁻³⁸ to ±3.4×10³⁸ (that's 10 to the 38th power)

In the new version, we could have it either way. I could keep the ranges the same as they are, or I could move to 64 bit versions

64-bit Integers: -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
64-bit Floating Point: ±2.23×10⁻³⁰⁸ to ±1.80×10³⁰⁸

(Now the ranges for the floating point values might not mean much to you, but suffice to say that many numbers cannot be represented exactly using floating point numbers. Even with the the 64 bit floating point number, the true representation of 0.1 internally is 0.1000000000000000055511151231257827021181583404541015625. It's just that Isadora only displays four numbers after the decimal point. Suffice to say that 64 bit floats are more accurate than 32 bit ones in terms of this error.)

There is only one use case I have encountered where the 32 bit version held me up: I was trying to import timestamps using the Data Array actor that were expressed as microseconds since Jan 1st, 1900. (I think this is some kind of standard.) The 32 bit float cannot represent this number, and so I had to write a program use a reference date that was Jan 1st, 1980 instead.

For most of what we do, the 32 bit versions have been adequate. The upside of 64 bit is more accuracy. The downside is that it will significantly increase the size of your .izz files if you have a complicated patch, because ever single number (i.e., an input or output to an actor) will now take 8 bytes instead of 4.

Does anyone have thoughts on this?

Best Wishes,
Mark

bonemap

@mark said:

thoughts on this

If I understand this correctly, the question is about potential increase in file size vs. numerical accuracy? What about file efficiency, cycles and FPS - are there any other anticipated impacts that differentiates the two options?

If the only impact is in the difference in project files size, I have reviewed my patch collection and the average and maximum sizes of my Isadora project files? I would rarely exceed 3-4mb file size and would imagine an increase of up to 10mb file size would be acceptable in favour of more numerical accuracy. But do we have enough information in @Mark's post to make an informed comment about this? I don't mean to doubt a master - just making an enquiring query.

Best Wishes,

Bonemap

LPmode

I would say make it for the future so make it 64bit. We want to be able to explore any new possibilities it has to offer even though we may not know what they are.

The file size should not matter but I do have one issue with bigger file sizes, - currently Isadora freezes while saving. and the bigger the patch, the longer the freeze. I submitted it as a bug maybe over a year ago. I had 10mb+ patcehs that would hang Isadora for over 10 seconds while it was saving.

mark

@bonemap said:

What about file efficiency, cycles and FPS

Good point... and it is something that I have already looked into. My research so tells me that there won't be measurable difference on performance, because – internally on all modern Intel processors – the size of the floating point value doesn't affect performance. Here's quote from one Stackoverflow article on the topic:

The classic x86 architecture uses floating-point unit (FPU) to perform floating-point calculations. The FPU performs all calculations in its internal registers, which have 80-bit precision each. Every time you attempt to work with float or double, the variable is first loaded from memory into the internal register of the FPU. This means that there is absolutely no difference in the speed of the actual calculations, since in any case the calculations are carried out with full 80-bit precision. The only thing that might be different is the speed of loading the value from memory and storing the result back to memory. Naturally, on a 32-bit platform it might take longer to load/store a double as compared to float. On a 64-bit platform there shouldn't be any difference.

In the end, the video processing (even on the GPU) and the disk throughput are the two factors that affect Isadora's performance.

Best Wishes,
Mark