Resolume Forum

He2neg So nobody ever asked me about my programming skills. And I worked as a professional programmer for almost 20 years ...

AEK wrote: Fri May 07, 2021 17:36 He2neg So nobody ever asked me about my programming skills. And I worked as a professional programmer for almost 20 years ...

You sure can offer your help and share your skills


I mean you are active in this Forum since a bit more then a year. The ppl i talk about are here since I can remember and also had some addons special programms as plugins or addons for resolum and so on.
When you are staying active and proof your skills I´m sure sooner or later you will get some message.

Zoltan was one of them before he got grabbed / imprisoned by the resolum devs and now he need to use his/her real name and i cant remember the "old" name to make the joke work.... =/

AEK wrote: Fri May 07, 2021 11:52 Oh, that's how ... Ie only kind and helpful people are allowed to beta testing. I didn’t make it on this list. Thanks for clarifying. Now I know.

Yah, they have a sign on the front door that makes you ineligible.

Zoltán wrote: Wed May 05, 2021 18:12
The OSC Tempo divide not worky issue number in the system is #14951 you'll find this in the release notes when it can be fixed.

Arena 7.3.3 was released today. But, in the list of fixed bugs, I did not see number # 14951. At the same time, 5 later ones (# 14956, # 14987 ...) are in the fixed. How can this be understood? Do you fix not all bugs, but only those that you consider necessary to eliminate? Or is there some other principle?

We currently have 2319 open issues and 13 members on the team. 9 of those are working on the code. So while we do want to work on each and every issue/request, we simply don't have the time to do so.
As a result we need to weigh issues depending on their severity (feature request, bug, crash), impact (number of affected users) and how well it fits with plans for the future. Then depending on how long an issue would take to solve they get sorted so that we're working on the issues with the highest potential first.

For example, lets say we've got a feature request that we think would benefit 1% of our users but it takes 1 developer four weeks to implement. And then on the other hand we have a bug report that takes two days to solve and affects 10% of our users. Which of these issues should a developer spend his time on?
We're choosing the second one, and yes, even if the bug was reported later than the feature request.

One Tip: In general when someone sais you should 'wait' for the issue number to pop up in the release notes, you shouldn't actually wait for us until we've solved it. You should either find a workaround or some other piece of software that can do what you want. Then you can do the show you need to do now and if/when we get to the issue you need solved in the future then perhaps you could try to do it with resolume then.

^ Yup

Still waiting 6 years on my keyboard shortcut for the test card lol

Menno wrote: Tue May 11, 2021 17:43
One Tip: In general when someone sais you should 'wait' for the issue number to pop up in the release notes, you shouldn't actually wait for us until we've solved it. You should either find a workaround or some other piece of software that can do what you want. Then you can do the show you need to do now and if/when we get to the issue you need solved in the future then perhaps you could try to do it with resolume then.

Nice way. And it seems to me that it would be correct to offer us a workaround for solving our problem. But, within 6 months from the side of the developers, this workaround was not offered to us. Maybe you can offer it now? And I find it very strange that the developers do not consider that the issue of high-quality synchronization of VJing with music is not a matter of paramount importance. In my posts, I have repeatedly raised the topic of the reason for the lack of flexible (adaptive) synchronization of animation of clips to the musical tempo in Resolume. The functionality implemented through the Ableton link does not provide the necessary flexibility. This has already been repeatedly confirmed by many users on this Forum. For some reason, Resolume still does not have its own built-in BPM detection module (similar to Waveclock), I also do not understand ... Yes, Resolume has buttons that allow you to change BPM in multiples (/4, /2, *2, *4). But, this all works exclusively in manual mode. As soon as Resolume receives BPM from an external source (midi clock or ableton link) the buttons stop working.

drazkers wrote: Mon May 10, 2021 03:40

AEK wrote: Fri May 07, 2021 11:52 Oh, that's how ... Ie only kind and helpful people are allowed to beta testing. I didn’t make it on this list. Thanks for clarifying. Now I know.

Yah, they have a sign on the front door that makes you ineligible.

^ This....
Again, maybe a good idea to email direct?
Everyone has different priorities, What you want may not be what the majority of the users want.
There are a lot of things I want that Resolume doesn't feel needs to be included, so I did just what Menno suggested and built my own tools for those niche things a smaller group of users might want. The stuff you are wanting to do can be done one the side using work arounds. If these things are so "crucial" to your workflow, I would get busy building workarounds rather than waiting

Arvol wrote: Tue May 11, 2021 21:10

drazkers wrote: Mon May 10, 2021 03:40

AEK wrote: Fri May 07, 2021 11:52 Oh, that's how ... Ie only kind and helpful people are allowed to beta testing. I didn’t make it on this list. Thanks for clarifying. Now I know.

Yah, they have a sign on the front door that makes you ineligible.

^ This....
Again, maybe a good idea to email direct?
Everyone has different priorities, What you want may not be what the majority of the users want.
There are a lot of things I want that Resolume doesn't feel needs to be included, so I did just what Menno suggested and built my own tools for those niche things a smaller group of users might want. The stuff you are wanting to do can be done one the side using work arounds. If these things are so "crucial" to your workflow, I would get busy building workarounds rather than waiting

Arvol , As far as I remember, you suggested using OSC as a workaround. And what came of it? It turned out that Resolume cannot implement this path. Therefore, there was a topic about the OSC bug. I also tried to solve the problem by using a multiple toggle animation speed. But, changing the animation speed by /2 or *2 times gives noticeable jumps and stops working when switching decks, which is unacceptable. Any more ideas?