OSC command "/vimix/session/load" does nothing

[ThomZenTury]

Hi there, first of all a big THANK YOU for your great program. I am fiddling around with it and it's way more fun than everything I tried so far.

I am using OSC commands (Open Stage Control) for a lot of actions and cannot get the "/vimix/session/load" command to run.

Specs: Linux Mint 20.1 Ulyssa Vimix 0.7.3 (tried both: compiled version as well as installed from flathub)

I use "oscsend" and "oscdump" trying to get this working.

The following commands work flawlessly: oscsend localhost 7000 /vimix/session/open s /path/to/file oscsend localhost 7000 /vimix/session/close oscsend localhost 7000 /vimix/session/version f 1

Troubles occur when I want to load and open another .mix with a transition.

What I tried and wwhat ends in simply opening the new .mix with a "hard cut": oscsend localhost 7000 /vimix/session/open /path/to/file f 5.0 oscsend localhost 7000 /vimix/session/open /path/to/file f 5 oscsend localhost 7000 /vimix/session/open /path/to/file 5.0 oscsend localhost 7000 /vimix/session/open /path/to/file 5 trying the "load" command as suggested in your wiki, nothing happens at all: oscsend localhost 7000 /vimix/session/load /path/to/file f 5.0 oscsend localhost 7000 /vimix/session/load /path/to/file f 5 oscsend localhost 7000 /vimix/session/load /path/to/file 5.0 oscsend localhost 7000 /vimix/session/load /path/to/file 5 oscsend localhost 7000 /vimix/session/load /path/to/file

It would be extremely helpful if you could point me in a direction what I could try next. I hope to read from you! Have a nice day! Thomas

P.S.: And if I may add another question: Is there a way to control a whole group of clips (I marked 4 clips and linked them in the GUI) with a single OSC command? I can't find anything about groups/linked clips in the wiki.

[brunoherbelin]

Thanks for your kind message, for discovering this issue and for documenting it. It should be indeed fixed and i will investigate !

This should be fixed in the next release; it would however be great if you can test before: are yo building vimix from source? OSX or Linux?

[ThomZenTury]

Hi again!

A kind message is the least I can do for the great opportunity of using this wonderful piece of software. If it is interesting for you: I would be up to do some tutorial videos on combining Open Stage Control and Vimix.

Indeed, I am building vimix from source on a Linux Mint 20.1 Ulyssa System with all suggested dependencies and libraries except shmdata. To make sure it's not a system problem I also tried the precompiled version 0.7.3 from flathub, but unfortunately it doesn't make any difference. Btw: the oscdump output when using "load" command is just empty.

I can gratefully do any further testing. I just need hints since I am not much of a software developer.

Thanks for your fast reply and have a nice day!

[brunoherbelin]

So, I checked and the problem seemed to be in your command :

e.g. in oscsend localhost 7000 /vimix/session/open /path/to/file f 5.0 the list of arguments should be after the list of corresponding types : s => 1 argument of type string f => 1 argument of type float sf => 1st argument of type string, 2nd argument of type float

The correct command is thus:

oscsend localhost 7000 /vimix/session/open sf /path/to/file 5.0

This works on my machine, hopefully for you too!

I corrected the documentation which was incomplete and with a mistake : thanks for pointing it out.

[brunoherbelin]

Now, regarding your other question: very good suggestion, I added a target /vimix/selection to target multiple sources.

For a specific list of sources, the target selection#i allows targeting the "Selection #i" at index i saved in the Player (i.e. created by user in Media player). For example, to play / pause multiple sources in selection number 0, the OSC command is /vimix/selection#0/play.

[brunoherbelin]

BTW, these changes are only made in the beta branch (currently under development)

git clone -b beta https://github.com/brunoherbelin/vimix.git

[ThomZenTury]

And my day is suddenly sweeter than before! Twice!

Thanks for the "opening" arguments correction. This works exactly as expected! And it's fun to watch.

The beta is compiled. The "selection" feature is working as promised. I did not even know about the "store selection" feature in the media player. Wohoo! The OSC commands work well for it. Although it does not seem to be possible to throw cloned copies into a selection. They are also not listed in the "source" dropdown menu in the media player. But, well, I am happy for today.

You asked about naming: I am always glad when OSC commands can be identical with the naming in GUIs (if present). So, it feels just right if you name it "selection#1" because it's just the same as in your GUI. Something I can remember! But I understand the issue of not being 100% accurate. I'll think about it further.

Thanks a lot!

[brunoherbelin]

Good that it works!

About the media player selections: it seemed logical (but can be discussed) to only allow sources that are 'playable' (i.e. can play and stop) to the Player selection.

So, by default a clone is not 'playable' (i.e. a passive replica of the original source) so is not integrated in the player. This could be expected because if you pause / play the original, the clone does exactly the same.

A clone however becomes playable (i.e. separately from its origin) if it has a filter, because the filter can be controlled to be itself playing / paused. Thus, a clone with filter can be integrated in the player selection.

That said, although logical from a computer point of view, I do agree that this can be confusing. Even more so because I added the possibility to see the frame in the player of a non-playable source, like an image. If the idea was to allow the user to look at the pre- and color post-filtering of an image (and just to be able to inspect it closer), I am aware that this can cause confusion. Why can I see the source in the player but not add it to the selection?

Your opinion would be helpful here:

• either accept any type of source in the player (AND in the selection, even if not playable)
• or accept only playable source in the player (BUT then cannot see a source in the player if its an image)

What your be your take?

[brunoherbelin]

Example above: if the Player accepts any types of sources (like clones or images in the bottom) then the Player user interface is a bit weird: these sources do not have a timeline ! What should it display?

Accepting all types of sources would be good for a more general use of these selections (e.g. as for targetting a selection with OSC). I would be in favor of this. But then the concept of 'Player' is a bit off... I am a bit hesitant on what makes more sense for the user...

[ThomZenTury]

Now pieces come slowly together! I admit I was confused about the overall "linking/grouping/selection" possibilities in vimix. I think with your explanation I slowly understand your approach.

Just for the record this is how I understand it so far:

1. "linking" several clips in the "mixing view" is more for better arranging clips and overview/workflow (although you can blend in/out a linked group by moving just one member of it there is no OSC influence)
2. "selection" is what you do and what you can use in the media player and is therefore meant to be a fully functional mixing group (that can be used with a single OSC command at once)
3. but "Settings -> Edit -> Group active sources" is still a bit of a miracle to me. Is it the same as "linking" clips like described in 1. and giving all of them 100% alpha?

Nonetheless, with that in mind I give your first question about "naming" conventions a second thought and I understand: you are asking for an overall name but "selection" not only for the OSC part. The only one that comes to my mind is "pool". Maybe a candidate? "Store selection" becomes "Create Pool" ? "Selection #0" becomes "Pool #0" ? But I still like the fact that I read "selection" in both menu options. It makes clear that these somehow correlate.

The types of sources question: I completely understand your definition of "player". But isn't a single image also "playing"? Just in an infinite loop? Maybe the quarter of a century that I have been working with moving images would never leave me irritated if your player wouldn't show me a timeline for a single image that I imported myself buuuut... I see! Could a one liner like "single image - no timeline available" next to the source's image in the list be a compromise?

Thanks lot for the advice to use filters to make a copy of a clip reachable in the sources list. Works perfectly!

Again! Thanks for the opportunity to use your project and for involving me.

[brunoherbelin]

Excellent ! Thanks for exchanging on these design and interaction concepts! My goal in vimix is to be clear without needing to read the full documentation but it is not always easy, and often, not always how others understand it. Please find below some elements of discussion so that we can progress.

"linking" several clips in the "mixing view" is more for better arranging clips and overview/workflow (although you can blend in/out a linked group by moving just one member of it there is no OSC influence)

Exactly, it could also be called 'connect'. The links (in green) only operate to create a mechanical connection to move one source to have effect on multiple. It is useful for blending (see video)

"selection" is what you do and what you can use in the media player and is therefore meant to be a fully functional mixing group (that can be used with a single OSC command at once)

yes, the idea is that, often, we select multiple sources and want to act on all of them together. Often it is the same sources we select together. So these selections can be stored.

I like your wording of 'pool' : mostly because then it can be 'Create pool' / 'Delete pool', without confusion of acting on all sources (i.e. 'delete selection' would be misunderstood as delete all sources selected). I will try and see how this looks once in the GUI.

but "Settings -> Edit -> Group active sources" is still a bit of a miracle to me. Is it the same as "linking" clips like described in 1. and giving all of them 100% alpha?

aha, yes, I changed the wording of this at least 3 times!!! Thanks for your feedback. What it does is the same as in photoshop for 'Flatten layers' : it takes the multiple sources and renders them together as if it was rendered as a vimix session. It is equivalent to creating a source from a file with a '.mix' file (instead of a video or image). This is powerful as it allows recursively integrate mixing sessions into meta sessions.

The 'edit / Group active sources' creates a session into the session; as such, it 'flattens' the visible sources into one source. So I first called this operation 'Flatten' : maybe it would be more clear? (but it was not clear to everyone neither). Once you have done this, you have one source that contains all the sources that were in the mix. How should this source be called ? A 'Flatten session' ? This is why it seemed to be more clear to call it a 'Session group' ?? I am open to any suggestion. (NB: other softwares do not do this recursive integration of a mix into a mix, so I did not have examples to follow).

I stop here as there would be more to discus but its already enough. I also on purpose do not give too much suggestions here as I appreciate your input from another point of view (e.g. your input for suggestion 'Pool' is original and I never though of it like that: it could be the solution!!). Thanks !!

[ThomZenTury]

And another "OH"! Now I know why vimix complains about a missing .mix file although I try to open a completely different one. Piece by piece... That is truly unique. Never seen or worked with a feature like that. On first thought I like this very much. I am a bit short on time at the moment but my brain wants to translate this into a "nested mix" or a "submix". Yes, "submix" is easier. Maybe it can help. Will get back to you soon...

[brunoherbelin]

I agree the current wording is not clear and was thinking of how to clarify all this... Here are options I am considering:

• "Link" seems appropriate. Nothing to change here. Or you think 'Connect' is more clear?
• "Batch" (instead of Selection) could clarify the benefit or making groups for addressing commands to a selection of sources. Player could have menu entries "Create batch" and "Delete batch".
• "Bundle" (instead of Group) could clarify the concept of nested session inside a session: edit action could be "Create bundle from active sources". The source itself is a "Bundle mix" or "Bundle session". Your suggestion for 'nested' is nice too, but the terminology of 'bundle' seems more common and maybe easier to understand? Of note, a source created from a .mix file could be a 'Child Session'.

Still playing with options here. I am in no rush to finish the Beta version :)

[brunoherbelin]

Working on 'Batch' operations in Beta version.

oscsend 127.0.0.1 7000 /vimix/batch#0/alpha f 1

Starts to be working fine. A few bugs to fix...

NB: The 'Pool' wording has a specific meaning in computing of a list of elements not used but kept aside, that can be pooled out. This is why i am not sure its the best. The term 'list' of the player evokes a 'playlist', which is something different (a list of media to read one in sequence). In any case, changing 'batch' to something else is easy ;) More suggestions welcome.

[ThomZenTury]

Finally some time to test the updates.

* "Link" seems appropriate. Nothing to change here. Or you think 'Connect' is more clear?

No, you're right. I think "Link" sounds just adequate.

* "Batch" (instead of Selection) could clarify the benefit or making groups for addressing commands to a selection of sources. Player could have menu entries "Create batch" and  "Delete batch".

Yes, "batch" also sounds familiar and I could get used to it (although it seems to come from raw computing stuff when doing batch processes on multiple files). Only other term I can come up with is "stack". Maybe?

* "Bundle" (instead of Group) could  clarify the concept of nested session inside a session: edit action could be "Create bundle from active sources". The source itself is a "Bundle mix" or "Bundle session". Your suggestion for 'nested' is nice too, but the terminology of 'bundle' seems more common and maybe easier to understand? Of note, a source created from a .mix file could be a 'Child Session'.

Oh yes, "Bundle Session" and "Child Session" would definitely clear things up.

NB: And again I found a useful tool in your box. I wasn't aware of the "Inputs mapping" window! Thanks!

And another question if I may: is there a way to get the clips into the "inactive area" of the mixing view by OSC commands, well, to make them inactive so that they are not playing anymore? I have a session with a lot of clips and it seems near the end of my mixing journey via OSC commands my PC seems to cough and beg for air because of too many clips playing simultaneously.

I really appreciate your efforts here. Thanks again!

[ThomZenTury]

Oh, and sorry for getting greedy now, but it would be just wonderful if the "vimix/current/sync" command would sent back also the values of all "batch#n" groups. If there's anything I could do to help please let me know!

[brunoherbelin]

TO BE TESTED please : in beta branch, commit c7367ad46a0ae5b3b0b60c96830ca27b6a41d62c enables the use of negative alpha values to send sources outside of mixing circle, i.e. for alpha at -1.0 (minus 1), the source will be inactive.

Should work with OSC message and Input Mapping.

[brunoherbelin]

Oh, and sorry for getting greedy now, but it would be just wonderful if the "vimix/current/sync" command would sent back also the values of all "batch#n" groups. If there's anything I could do to help please let me know!

Not sure to understand : if you ask for /sync, you have a response with a complete list of sources : oscsend 127.0.0.1 7000 /vimix/current/sync f 10 will list 10 sources

Or maybe you mean to list which sources indices are part of a Batch ? e.g. that /vimix/session/sync would lead to the response on session to include a info bundle on all batches?

[ThomZenTury]

TO BE TESTED please : in beta branch, commit https://github.com/brunoherbelin/vimix/commit/c7367ad46a0ae5b3b0b60c96830ca27b6a41d62c enables the use of negative alpha values

Thank you so much! Yes it works. I can now set the clips to "inactive" by moving them to about -0.35 alpha and further.

Or maybe you mean to list which sources indices are part of a Batch ?

Sorry for not thinking over my question. It's indeed not very clear. What I meant: is it possible for vimix to send back a list of "selection#n" alpha values (or other parameters like loom etc.)? Just like I send out OSC commands "/vimix/selection#n/alpha f 1.0" to get back exactly that information later on by sending "/vimix/session/sync"? Usecase is: I have one OSC slider controlling a selection's alpha value by "/vimix/selection#0/alpha. The slider has multiple jobs on a selection to do. By pressing buttons I can switch through these different jobs (alpha, grab, resize etc.) and it would be awesome if it synchronizes with the values of the chosen job. Or is "selection" just a sort of container that stores the names of the selected clips? Then I could see the problem with syncing.

[brunoherbelin]

Thank you so much! Yes it works. I can now set the clips to "inactive" by moving them to about -0.35 alpha and further.

Good! Note that the diameter of the outside mixing circle can be adjusted: to be safe, -1.0 is sure to be inactive

Just like I send out OSC commands "/vimix/selection#n/alpha f 1.0" to get back exactly that information later on by sending "/vimix/session/sync"?

Well, I fully understand your use case, but it does not generalizes: there is not one value of Alpha for a batch (selection) because each source has its alpha value.

Example : when you send /vimix/batch#n/alpha f 1.0 all sources in the batch are now to alpha 1., But then afterwards you can always send /vimix/0/alpha f 0.5 (or use the vimix interface) to change one single source. Consequently, if the source 0 is in the batch #0, this means that now the batch #0 has some sources at alpha 1,0, and one source at alpha 0.5 ! Vimix cannot give a unique value for batch#0 alpha !! Should it give the mean alpha? No; this is not a value which represents the reality.

So, only in the special case of your usage, because you might be sure in your way of working that you do not modify individually a source inside a batch, you could read the value of any of the source inside a batch and consider it representative of the whole batch. In this case, you could use the value of one source to update the slider for this whole batch. In this case, what could help your program to know which source alpha to read in order to represent the alpha of a batch would be to know the list of (indices of) sources in that batch. This is why I was suggesting that a /vimix/session/sync could return the list of sources in all batch. But indeed, this means a multiple steps of programming is required on your side.

[brunoherbelin]

okay, I have something to suggest : status of all batch listing all values (unsorted)

example request; $ oscsend 127.0.0.1 7000 /vimix/current/sync

reply:

e79a53aa.0ab430f4 /vimix/current/name s "DSCF5591"
e79a53aa.0ab430f4 /vimix/current/lock f 0.000000
e79a53aa.0ab430f4 /vimix/current/play f 0.000000
e79a53aa.0ab430f4 /vimix/current/depth f 2.617887
e79a53aa.0ab430f4 /vimix/current/alpha f 0.886544
e79a53aa.0ab5e529 /vimix/current/0 f 1.000000
e79a53aa.0ab5e529 /vimix/0/alpha f 0.886544
e79a53aa.0ab5e529 /vimix/0/name s "DSCF5591"
e79a53aa.0ab5e529 /vimix/current/1 f 0.000000
e79a53aa.0ab5e529 /vimix/1/alpha f 0.399893
e79a53aa.0ab5e529 /vimix/1/name s "DSCF5588"
e79a53aa.0ab5e529 /vimix/current/2 f 0.000000
e79a53aa.0ab5e529 /vimix/2/alpha f 0.399893
e79a53aa.0ab5e529 /vimix/2/name s "vlcsnap-2021-09-04-13h22m19s399"
e79a53aa.0ab5e529 /vimix/current/3 f 0.000000
e79a53aa.0ab5e529 /vimix/3/alpha f 0.371969
e79a53aa.0ab5e529 /vimix/3/name s "vlcsnap"
e79a53aa.0ab5e529 /vimix/batch#0/alpha ffff 0.886544 0.399893 0.371969 0.399893

Would that work?

[brunoherbelin]

So, I implemented a mechanism that should be working.

Sending /vimix/session/sync or /vimix/batch#0/sync or upon events changing alpha of sources in the batch leads to the response status from vimix, e.g.

e79d0ffb.105f9df5 /vimix/batch#0/index iii 3 1 4
e79d0ffb.105f9df5 /vimix/batch#1/index ii 2 0
e79d0ffb.105f9df5 /vimix/batch#0/alpha fff 0.000000 0.000000 0.000000
e79d0ffb.105f9df5 /vimix/batch#1/alpha ff 0.000000 0.773361

This is only in Beta now, so can be changed.

[ThomZenTury]

What a great start into the week!

Should it give the mean alpha? No; this is not a value which represents the reality.

Yes, you are completely right. It would only be useful for my individual case. But with that:

So, I implemented a mechanism that should be working. Sending /vimix/session/sync or /vimix/batch#0/sync or upon events changing alpha of sources in the batch leads to the response status from vimix, e.g.

I am again more than happy and going to test thoroughly soon. Some duties keep me busy at the moment.

I cannot thank you enough!

[ThomZenTury]

Finally I have some time to test your achievements. And what can I say? Everything concerning the OSC commands around batches works as I wished. With a little workaround the batch#n/alpha values sync flawless to my OpenStageControl GUI. Thanks!

There are other two things I encountered though, that have nothing to do with all the above:

1. The "Bounce" playmode in the player seemed to "hang" itself if the clip was customly cut at the end. This did not happen when I left the clip untouched to full length. Also, it happened only when cutting the end of the clip, not the start. But trying to recreate it now gives me nothing. A bug that you already fixed? I could swear it was in this version (0.7.3 beta compiled Friday last week).

2. Is it normal that when loading and opening a new scene with a transition (let's say 3 seconds) there is a little "freeze" happening. It is stuttering maybe for a quarter of a second. And no matter how small the clips, how empty the projects and how light the overall system runs I cannot seem to get rid of the little hickup. I am not too bothered but it would be nice to know why? And if it is something concerning only my system.

Have a nice day!

[brunoherbelin]

Everything concerning the OSC commands around batches works as I wished. With a little workaround the batch#n/alpha values sync flawless to my OpenStageControl GUI. Thanks!

Excellent ! Closing this issue then !

The "Bounce" playmode in the player seemed to "hang"

Probably related to #68 : please check and complement the bug report if you have more information

Is it normal that when loading and opening a new scene with a transition (let's say 3 seconds) there is a little "freeze" happening. It is stuttering maybe for a quarter of a second.

Definitely not 'normal' in the sense of intended behavior. It should not hang and be smooth...

And yes, I could reproduce it. it happens each time, and is really very annoying : i will fix this !!!