@mark said:

I will come back to this if the popularity of using this editor warrents.

 I would advocate for the built-in editor to be effective for small tweaks when prototyping (and it is already until it becomes unresponsive). There is a complication around versioning that would be better facilitated through a linked external editor. By accessing the shader code from the file and being able to save directly back to the file in the glsl folder would provide a benefit to assist versioning custom shaders.

best wishes

Russell

@mark said:

next version will have this ability. (As well as a few others to make it easier to replicate ISF shaders.)

 Great news!

Best wishes

Russell

@lpmode

I just forked this comment off from the other post and put it in the feature request section so we can keep better track of it.

Great idea!

Best wishes,

Woland

@jfg said:

.USDZ and/or .glb

 I think if we could just get the addition of the .OBJ file format for 3D models supported would be great start!

Best Wishes

Russell

I loved The Edge (I think it was called). It always seemed to be in auto-arcade-game-mode and made everything look very 80s (in a good way), but with a bit of care you could turn it into glorious line drawings.

I'm sure I got a lot of use out of a classic kaleidoscope as well, unless I imagined that and it was always a CI or Quartz actor of the same name. Rarely used it as an actual kaleidoscope but it was a really quick way of creating single reflections. In workshops people love 'disappearing' into themselves or dipping under water with a horizontal reflection.

I'm sure I used TimeBlur fairly regularly, although I'm not sure I ever fully understood it. Wasn't there a TimeWarp as well? If not, there should have been.

Hi,

It would be great to see an incremental update or refresh of the 3D space and modules in Isadora. 

Some of the attributes screaming for an update and top of my list are: 

1/a depth map feature

2/expanded file format compatibility

3/update to z index, back face and layering attributes

Best Wishes

Russell

@woland what it does: when i replace a profile unit wit a par64 it would keep the basic information about focus, color, purpose, patch number..ect

but as i said. it was just an idea after all

Hello,

I create for my job interfaces to control external equipment via TCP/IP commands and 4 stream id is not enough for my intent.

It would be great to have the possibility to control a higher number of peripherals.

Thank you

Stefano

We've already received this and logged it as a feature request, but I will add this post to the feature request.

Best wishes,

Woland

I agree with Fred and asked this before. In complex mapping situations I leave out (if possible) the projector out of a group for this reason.

Ah, I'm being thick. It took me a bit to understand your use-case wherein sometimes User Actors might have different names (because of position/function) but that you'd still want them to be part of the same "group" and update together (or ones with matching names being part of different groups and not updating together). I can definitely see how what you're talking about doesn't currently exist and could be helpful. 

(To be transparent, even though I'd personally love it now that I understand what you're saying, it's a very power-user-centric feature request so it may end up lower on the list than other feature requests that would affect a larger percent of our userbase. Like I said, I love the idea though.)

@fred

All excellent points. I can see how this would be a very valuable addition to IzzyMap. Thank you for taking the time to give us feedback 🙂

@mark
I agree the Maximum and Minimum should be Min Max in the same ways as Z translate.
The Scale Min and Scale Max can remain as -360 and 360.
The use case you just went thru is for very advanced users for sure!
And as you have said, for anyone new trying it, having a meaningful range defined by default will help.

My concern is more with the level of visibility of these 'hidden' input settings.
I know we have talked a fair bit about this issue and a few UI changes have been suggested to make it easier to visually see where scaling is happening, but making the current values more visually obvious would also be cool. However, this is something we need to discuss deeply.

The built in scaling is great, and can make things very fast.(compared to always adding 'limit scale value')
But adding 'limit scale value' happens to be my go-to method.. since it makes editing/understanding the patch months later much easier.
If we could see where scaling is occurring and easily see the From->To of the scaling it would go a long way to making this feature safer to use/rely on.

edit:

and maybe to route audio in on the transmitter side?

j.w.

I would love an unload scene actor. Something that is essentially the opposite of the preload scene actor. There are times where I'll need to preload a scene in order to tighten up a transition but in the course of cuing you may skip the loaded scene and then have a bunch of media loaded when not needed. It would be great to have an unload or something to cancel/clear the preload scene that I could trigger when needed.  

I have a case where I want to use a user actor for mapping a lot of small pieces, but I want to use the same mapping for an alpha layer, but the pieces in the two need to have different blend modes. It would be great if the projector blend mode had some other options, like when the mapper was engaged the blend modes still worked, so they could be additive, transparent opaque OR mapper. and when the mapper was used and transparent was selected it would set all the mapper pieces to transparent. If it was set back to mapper then it would use the blend setting of the individual pieces. I think there are other options for doing this, but a way of having the smae mapping with different blend modes for using alpha layers with different projectors into the mapper would be cool.

@woland

thanks a lot for the examples 

Matthias

@mark

Thank you for taking this seriously and investigating every avenue. I can only imagine the frustration...

@ughoenig said:

I see the problem with floating point numbers, but it would still be very nice with integers.

Implementing this in some cases and not others would be confusing for many users because the feature would seem inconsistent.

Thank you @dusx,

I know the workarounds. Those where described in the linked topics as well as comments by Mark about this.

I just thought this feature request forum category is meant to  keep track of the those and to see how many users would be interested in them?

Am I wrong about this?

Dill