Pythoner and Isadora 4 as yet unknown features

Fred

The new Pythoner actor is great and does some amazing work to expand the possibility of Isadora. Great work on this well needed feature.

I have an important feature request for this actor and would really like to have a discussion and explanation of the limitations of this design.

Having the outputs of this actor locked to the return statement of the python code feels like a very heavy handed limitation. This means that we cannot really use any python timings or standard routines inside that actor- every time we want to run the code we are limited to when Isaodra might trigger an event - something we have no control or feedback over when it might happen.

The pythoner actor runs in its own thread and not being able to run a loop inside this actor without relying on Isadoras timing is a big limitation. being able to run this code in a more standard programming paradigm would mean that this actor becomes much much more powerful. It could be used to make sequencers, use cumulative variable updates and intermediate and accurate timings - this is such a big deal. There is no real way to know when a trigger is fired in Isadora but python can let us do this with precise control. We can output precise events and not have to run goldfish style run once code in the actor.

My first question is can someone explain if this limitation with the pythoner actor is fixed- I asked about it in another thread and it was marked as logged - what does that mean? It sort of feels like its on the 'backburner'. Could it be addressed? Is it alwasys going to be limited like that?

On that note, this is an expensive upgrade and I am not sure whether to invest. There are other important features that didn't make it into this, the most obvious is routing of audio tracks from video files, which is such a common feature among free and paid competitors. The new upgrade path is a half subscription - we pay and get feature upgrades for 2 years which is great and offers some surety. However there is no road map, no idea of what we are paying for in these 2 years and no transparency over what features are on the list to come next and when.

As the community is being asked to invest in an unknown future feature set, and pay upfront could we have some transparency? Is there a list of features that are coming and the order or target dates they are planned for? Can we see what features are the most requested and what might be attended to?

There are many others like receiving OSC on multiple ports and multiple NICs,, better artnet pixel mapping, more control over slices in the mapper, and many more.

This forum is very responsive, but when features are marked as logged what happens? Can we vote on them and see the results from the community? Can we see what direction and features might be realised in the time between us investing in an upgrade that does have some cool stuff promises more things but misses a lot of heavily discussed feature requests?

I'm not adverse to the model, the price seems high, but ultimately it feels like we don,t know what we are actually buying in terms of the future.

Cheers

Fred

Woland

@fred said:

The new Pythoner actor is great and does some amazing work to expand the possibility of Isadora. Great work on this well needed feature.

I have an important feature request for this actor and would really like to have a discussion and explanation of the limitations of this design.

Having the outputs of this actor locked to the return statement of the python code feels like a very heavy handed limitation. This means that we cannot really use any python timings or standard routines inside that actor- every time we want to run the code we are limited to when Isaodra might trigger an event - something we have no control or feedback over when it might happen.

The pythoner actor runs in its own thread and not being able to run a loop inside this actor without relying on Isadoras timing is a big limitation. being able to run this code in a more standard programming paradigm would mean that this actor becomes much much more powerful. It could be used to make sequencers, use cumulative variable updates and intermediate and accurate timings - this is such a big deal. There is no real way to know when a trigger is fired in Isadora but python can let us do this with precise control. We can output precise events and not have to run goldfish style run once code in the actor.

My understanding of the Pythoner actor's functionality is limited, so for more detailed answers, you might need to wait until Ryan returns from his (well-deserved) vacation. From what I think I understand, to avoid "goldfish style run-once" code behavior, you can use Pythoner to launch a background thread or process that runs independently of Isadora. Then, you can use the same or another Pythoner actor to periodically check in with that process, for instance, 30 times a second using a 30Hz Pulse Generator. Alternatively, the background process can send data back to Isadora in real time via OSC. Our goal with Pythoner was to unsandbox Isadora by allowing users to run Python code and, while it may not be perfect for every scenario, it’s still a powerful addition to the software. I've already found it essential for personal projects that required SQL database features, interfacing with hardware APIs, and dynamically importing media from a watched folder.

@fred said:

My first question is can someone explain if this limitation with the pythoner actor is fixed- I asked about it in another thread and it was marked as logged - what does that mean? It sort of feels like its on the 'backburner'. Could it be addressed? Is it alwasys going to be limited like that?
[...]
This forum is very responsive, but when features are marked as logged what happens? Can we vote on them and see the results from the community?

We collect feature requests over time and then evaluate them all in focused sessions, as it's impractical to assess each new request against all the existing ones individually as they come in. Your Pythoner feature request, #725, is part of the latest batch that we'll be reviewing now that Isadora 4 is released.

When we log a request, we gather relevant comments, create an internal issue, or add it to a similar existing one. We document key details, including how many people interacted with the post, and summarize the main points so that we can later prioritize features based on interest, feasibility, and a cost-benefit analysis of implementation time versus user impact.

While we highly value input from power users like you, we also need to consider the broader user base and our limited resources, which means we can't implement every request we receive. For example, while WebSocket support would be powerful, it might not be as widely beneficial as our recent addition of help text to all the Controls and the Property Inspector to make them easier to understand and therefore more accessible. We always strive to balance specialized features with those that have broader appeal, so requests like WebSocket support and Pythoner changes are never discarded, but it's important to remember that we're a small team and each request is one among hundreds.

@fred said:

On that note, this is an expensive upgrade and I am not sure whether to invest. There are other important features that didn't make it into this, the most obvious is routing of audio tracks from video files, which is such a common feature among free and paid competitors. The new upgrade path is a half subscription - we pay and get feature upgrades for 2 years which is great and offers some surety. However there is no road map, no idea of what we are paying for in these 2 years and no transparency over what features are on the list to come next and when.

As the community is being asked to invest in an unknown future feature set, and pay upfront could we have some transparency? Is there a list of features that are coming and the order or target dates they are planned for? Can we see what features are the most requested and what might be attended to?

There are many others like receiving OSC on multiple ports and multiple NICs,, better artnet pixel mapping, more control over slices in the mapper, and many more.

This forum is very responsive, but when features are marked as logged what happens? Can we vote on them and see the results from the community? Can we see what direction and features might be realised in the time between us investing in an upgrade that does have some cool stuff promises more things but misses a lot of heavily discussed feature requests?

We'd love to offer the level of transparency, create a dynamic, community-driven roadmap like you're suggesting, and have already delivered on the feature requests you mentioned. However, doing so would require hiring more staff, including a full-time project or community manager and additional programmers, which isn’t possible for us right now. I’ll bring up the idea of increasing transparency and providing a roadmap in an upcoming team meeting, but with four out of our five core staff members going on staggered vacations soon, it may take a few weeks before we can all convene to discuss this.

We do have feature additions planned of course, but those were decided before Isadora 4’s release so we’ll need to review and adjust them and thus sharing our current roadmap wouldn’t be accurate or practical at the moment. This revision will involve long, focused meetings, and after the monumental effort that went into creating Isadora 4, and given that some team members are still working overtime, we hope that you and the rest of the community will understand that we need a little breather.

For now, we’re listening to and documenting all feature requests so that we can prioritize them based on the process I described earlier with the aim of adding as much value to the program as possible using the resources that we have.

@fred said:

I'm not adverse to the model, the price seems high, but ultimately it feels like we don,t know what we are actually buying in terms of the future.

Although, as I said, I can’t share specifics about upcoming features yet, we'll do our best to communicate our plans once they're ready for public consumption.

The decisions to modify the buy-to-own licensing model and increase the prices were driven by inflation and our goal of ensuring the company's future growth. I joined TroikaTronix because of their commitment to keeping prices as low as possible for the sake of artists, and after nearly a decade here, I’m proud to say that commitment still stands. While we can’t keep prices as low as they once were, none of us are in this for the money, and personally, I'm here because I love and believe in the software and this community.

Best wishes,

Woland

DusX

@fred said:

question is can someone explain if this limitation with the pythoner actor is fixed

You can absolutely run ongoing background processes in Pythoner via Threads or other parallel processing options that Python offers.

For example, I recently posted a script that addresses the issue of receiving OSC from multiple ports (see: Listening OSC over different ports on ISADORA 4 possible? | TroikaTronix Forum).

This solution utilizes threads to run a server that continually listens for incoming OSC messages. Isadora then polls the queue of responses using a trigger to the Pythoner actor. This method works very well, as the polling can be synced with the target framerate or even faster if required.

Over the coming weeks, I’ll be releasing several examples demonstrating how to run background processes, threads, and async in Pythoner. These examples should address many of the feature requests we've received, such as handling data via WebSockets. Additionally, I’ve been experimenting extensively with Pygame and am refining a few approaches that I’ll also share soon.

The approach we used with Pythoner was designed to allow users to get started with Pythoner in Isadora as simply as possible: write a set of commands, let the code run, and get a response. We’ve discussed potential extensions to Pythoner, but we need to observe how it’s being used to determine which additions will have the greatest impact.

When deciding on features, we review hundreds of feature requests, alongside collected user statistics and survey responses. As Woland mentioned, we are moving towards more transparent processes. We’re careful not to overpromise because, like you, we’re excited about new features and want to add all the cool stuff into each release. However, it’s easy to dream big, and the last thing we want to do is disappoint.

best regards

Ryan (aka DusX)

Fred

@dusx it will be great to see your examples. As I am impatient is there a way to selectively update one/any/all of the outputs of the pythoner actor without getting to the end of the code? Ie without needing to reach the return statement?

Fred

Thanks for the reply. I understand inflation is biting Troika. But as it does to everyone here and as do all the competing solutions that offer the same or similar features to isadora.

The company line is strong from these posts. There will be no advanced announcements of features. Also that by paying for this upgrade we are paying for future features in advance but will not know what they are or have an understanding of how anyone’s needs influences what is implemented.

I don’t think I’m alone thinking this is an expensive upgrade that has a lot of cosmetic changes but misses out on some regularly requested ones.

I understand there has been shifts in staffing for troika over the years but seemingly the coding is still all Mark who has made amazing contributions to media and performance and this software is just a part of that.

Again though we are asked to invest in an unknown future. Are there more developers in the pipeline to add features faster? If Mark stops coding what happens to the product?

The impact of inflation on my operation is making me invest in things more carefully. I need to know that the tools I invest in have a long future and will grow and expand as the industry does.

There are some cool improvements in this update, but is there something we can get about what this the costly upgrade means for the future. I understand I get 2 years of upgrades but what might that mean? Even without a specific list of features is there a mission statement for goals over that time or even the longer possibly post Mark future for isadora?

Armando

@fred Dear Fred, I also had similar thoughts on Pythoner and time management. Although Ryan is giving you another process that might help you, I am sure you'll be listened and your input considered, also because you are a great member of the forum as generous as creative.

I respectfully don't agree with your statement Concerning your statement on the "cosmetic changes”. In my opinion It is much much more than cosmetic. The read-me file is as long as an arm, and there are features that are unique like Izzycast, controls, new osc management and loads of other SDK updates that are needed (Blackmagic, NDI, etc.) things I am sure you saw.

You are right concerning sound improvements that are needed. As for the sound, there is one thing that will happen soon that I can say, although I cannot give details at the moment. Before saying it, I’ll say that I am not and have never been a Troikatronix employee in any form. I am an academic, an artist and a researcher. I created a well-funded non-profit organization in Canada, SIT Scènes Interactives Technologiques that supports artists who want to work with technologies and, of course, Isadora is the centerpiece of our work. Through Isadora and its developments, we support the live artist's communities. As of now, I cannot share details here, but with Troikatronix and other partners, we got a grant last April that will help the evolution of sound treatment in Isadora (even High Order Ambisonic sound). And I know, for administrative reasons I will not bore you with, that all of that might by up and running by the end of 2025. So... sound improvements are coming, and soon.

At SIT we are planning to continue to contribute to Isadora’s development in the future in order better to serve the live art and digital arts communities.

By the way, with SIT and Troikatronix as other partners, we are waiting for another grant’s answer. That will be for more developments in Isadora I am dreaming of and that are superexciting. I'll wait for the answer in the end of September, but if things are going the way we plan, Isadora will be the only software that will add a completely new way for performers or audience, to interact with the software. A new kind of real time interactivity. We want to contribute to the support and the future of Isadora because we believe in it. So, not only I have no reason to give up on Izzy, on the contrary, I strongly believe it’ll have a bight future. I believe in all that and the amazing team.

DusX

@fred said:

is there a way to selectively update one/any/all of the outputs of the pythoner actor without getting to the end of the code? Ie without needing to reach the return statement?

Hi Fred, I just returned from a little holiday where I was offline (no cell service) for the past week :)
So, I am just getting back into things today. The quick answer is no, this isn't currently possible. Generally, I spin up a thread, and have a loop/process running there, then poll for values from a que for output from the main function (called by a pulse trigger at 60fps or whatever my target is).
Defining another type of return statement that only outputs values but allows the code to continue to loop is an interesting idea that I know we are looking at. However it is not an option at this time.

Woland

@fred

Hello Fred,

As I mentioned earlier, I can’t provide detailed answers to your specific questions because of the long overdue staggered vacations that our staff are going on. However, I want to do what I can for you right now.

After reviewing your licenses, I realized you currently don’t have access to a license compatible with Isadora 4, which was an oversight on my part. I’ve now renewed your Beta Testing License and I am about to create a ticket in our system to send you the info via email. As a longtime power user of Isadora and a talented member of our community, it would be a real shame to see you go, so there will also be something in the ticket that will hopefully help make the financial decision of whether to upgrade easier for you.

Also, to briefly address one of the important points you brought up, as I said earlier, one of our primary goals right now is to ensure the future growth of the company. More specifically, we're aiming to bring more developers on board, as doing so will allow us to enhance feature delivery and assist with the ongoing development of Isadora.

Best wishes,

Woland