@dusx many thanks for your knowledge and the feature request consideration!

@kdobbe

I agree that it would be incredibly helpful for linear cueing, but one of the reasons we haven't gone in the direction of trying to emulate timeline-based software (which relies entirely on linear cueing) is because it would introduce a number of complexities (and some impossiblities) due to Isadora's focus on interactive cueing (e.g. video intensity or a transition being controlled by volume using a Sound Level Watcher or by sensors) and non-sequential cueing (e.g. A scene that's programmed to cycle through random Snapshots or an Activate Scene actor in scene 4 activating a background scene 2 with Sound or Movie Players) which simply cannot be tied into or accurately represented on, as you put it, "a timeline sequencer built directly into the interface". This timeline-based (and linear) engine would have to simultaneously exist alongside Isadora's current engine (where non-linear and interactive cueing is possible) and this gets extremely complicated very quickly.

That's not to say this isn't a great idea, it's a wonderful idea. The issue is that from a programming and User Interface/Experience design perspective, the thought, energy, and time required to create, test, and add a timeline functionality as one of the core mechanics of Isadora would be massive. I'm not saying that we can't or won't add this feature, (in fact I hope we do), but I can tell you that unfortunately, we can't implement it anytime soon, since we'd have to scrap a large number of the features that we're planning to implement in the near future in order to focus on incorporating a timeline into the heart of the program.

Best wishes,

Woland

@craigw

Currently there is no way of doing this type of multi-line move.
It's a great feature request, and I will add it to our list ASAP.

@bonemap

Neat idea. I've logged it. 

@michel

Well, @DusX experimented with this and found a flaw in the actors: you can still transmit and receive 64 universes, but it is the AN universe that can have only four values, not the AN subnet as it should be. Please read my post again, as I've updated everything so that it correctly reflects what the actors actually do. I wouldn't update your nice chart yet... we need to have a discussion of what it would mean to fix this.

To make this at least a little bit simpler, I've also added a table that gives you a list of universe values that will ensure you to use all of the 64 possible DMX universes.

I've also updated the examples to show how to transmit 16 distinct DMX universes, breaking it up into a Send patch and a Receive patch.

Finally, Michel, I have one question for you: should we rename the 'universe' input on to 'port-address'? What terminology do they use on your hardware for this value? 

Best Wishes,
Mark

@garygalbraith

As a workaround, you could consider some automatic mirroring software like Mirror Folders or AOMEI Backupper for PC.

I didn't find any kind of automatic app for this on macOS, but this command will create a synced JavascriptLibs folder in your documents folder.

rsync -va --delete "/Library/Application Support/TroikaTronix/JavascriptLibs/" ~/Documents/JavascriptLibs/

One nice way to automate this is to create an Automater script that runs at system startup

Open AutomatorChoose to create a new documentChoose the "Application" optionFrom the list of possible actions, choose "Run Shell Script"In the "Run Shell Script" Item that appears on the right, paste the rsync code from aboveSave the Automator workflow to your Documents folder as "backup-javascript-libs.app"Quit AutomatorGo to System Preferences > Users & Groups > Login ItemsClick the "+" button and enter your password if necessarySelect "backup-javascript-libs.app" from your documents folder and click Add

Now, every time you restart your computer, the JavascriptLibs is backed up to your Documents folder.

If you're comfortable with with a bit of low level stuff, you can go even further and schedule the rsync command to run periodically using cron. See this StackOverflow article for help on that.

Hope that helps,
Mark

@garygalbraith

Thank-you for the suggestion. I will add this to our feature request right away.

@bonemap said:

DISCLAIMER: I have not tested this functionality with the latest releases of Isadora so can not vouch for its current compatibility.

 

 I can confirm it works with Isadora 3.2.1

best Jean-François 

@zedociel

I have logged this request. Thank you for your input :)

@ahnahum

This is not currently possible but we have a feature request already logged for this.

Best wishes,

Woland

@clafarge @tlaloc

I dream of a day when I can manually set the format for each output to 'text', 'int' (with MIN MAX specified), 'float', etc. with intention.

We know. This request is already logged.

The reason I've hesitated on this previously is because of the conflicts that can be created by allowing it.

Let's say you specify that output 1 is a float, range 0 to 100. And then you specify that output 2 is text. You would do this in the source code of the Javascript actor, as it is now done with the output names.

So, when you close the editor, the Javascript actor happily changes its mutable outputs. Output 1 becomes a float from 0 to 100, and output 2 is text. Now you connect those outputs to actors that accept those data types, e.g., a Calculator for output 1 and a Trigger Text actor for output 2.

Now you go in and edit the source code, changing the type specifications so that output 1 is text and output 2 is a float from 0 to 100. But the outputs are already connected in such a way that output 1 must be a float, and output 2 must be text.

You could attempt to do a conversion. Converting a number to text will always work, but you can't convert the text "Mark" into a number, forcing you to output a zero. This option seems bad to me because users would could become confused by this behavior.

The other solution is to throw an error in the editor, telling you that you can't use the data types you've specified because the outputs are already connected to something else. I suppose this is the direction I would go, because the editor is sort of in a different "space" than the Scene Editor where you make connections.

Anyway, the complexities of managing this are the reason it hasn't been done already. But if more people indicate that this is a top priority for them, we can try to prioritize this feature.

Best Wishes,
Mark

@bonemap

I will add this to the Feature Request tracker, and I will add the Isadora version number as a default Meta data parameter.
I can see how this might be useful.

@jamie-griffiths said:

SND and TRK options remain greyed out

 These inputs are remnants from Quicktime, and remain only to allow older files to update without losing control links. At this time playing multi-channel audio in Windows requires setting the sound device to recognize the audio channel format. 

This article outlines the movie file setup (same for Mac and PC as far as the multiple audio channels) https://support.troikatronix.c...
Here I show the Windows settings for Quadraphonic, and 5.1 audio https://community.troikatronix...

Please open a support ticket, and I can look at one of your Movie files and recommend your next steps.

Logged  :)

@clafarge

This was an existing Feature Request, but I added the link to this post and your text to our internal version of the feature request.

Best wishes,

Woland

@tlaloc

This was an existing Feature Request, but I added the link to this post and your text to our internal version of the feature request.

Best wishes,

Woland

@celiomenard nice work! Is similar to what i did by my self. Nice that you shared your work!

@mark

Thanks for getting back on this issue... I just hope that Apple opens up this possibility to other virtual cam apps as well then : ) 

@tomthebom

The simple reason is that we're running out of keyboard shortcuts. We have a feature request already logged to make all keyboard shortcuts customizable by the user. It's not planned to be a part of our next release, but hopefully we'll be able to squeeze it in at some point in the future. I will add your post to that feature request since it would solve your problem.

Best wishes,

L Wilson-Spiro 

Because OSC in Isadora combines payloads with addresses, some of our more complex patches have actually begun to reach the limit of 800 channels for OSC. ZoomOSC for example has 180+ I/O commands which can receive between 4 and 12 payloads each.

Can we increase to 1000?