Does 4.12.1.16 allow multiple instances of Studio?

Hurdy3D

Richard Haseltine said:

I meant changes made in the auto-named instance - unless the shortcut of a deliberately named instance was edited to copy them.

Still don't get your point, but in the latest update the devs did excactly what I (and RayDAnt) asked for.

There's only a setting missing which starts will start DS with the automatic incrementation instances automatically, if the main instance is open... than everything would be perfect

Richard Haseltine

gerster said:

Richard Haseltine said:

I meant changes made in the auto-named instance - unless the shortcut of a deliberately named instance was edited to copy them.

Still don't get your point, but in the latest update the devs did excactly what I (and RayDAnt) asked for.

There's only a setting missing which starts will start DS with the automatic incrementation instances automatically, if the main instance is open... than everything would be perfect

Well, either I was wrong or it isn't seen as a major issue (not that i thought it was major, just a potential niggle with the approach). But Rob was clear that the approach you had originally suggested would not work, so I'm not sure how the balance of pros and cons played out there. I don't know that I'd want to have DS start a separate instance without a by-my-leave, though, so having a shortcut for that ana short cut for a plain launch which will fail if it's already running doesn't seem an unreasonable compromise.

Richard Haseltine

outrider42 said:

This does bring up a question, how will instances work from the different bridges to Daz from software. Like mentioned if you use the Daz to Hexagon bridge and then go back to Daz it will go back that same instance. If you open Hexagon from its exe and then send to Daz it will always open a new instance. So how will this be handled in the future?

I'd really like to see Daz offer the option of where the bridge goes, letting the user pick a current instance or open a new one.

 

Richard Haseltine said:

gerster said:

The only pitfall I saw was the random instance names leaves unused daz folders on the system.

But this issue is more or less fixed with a name schema.

I'm suggesting not to replace the cli arguments with my suggestion.

The idea is to give addtional the option to create automatically named instaces, if nesscery.

If you want the option to create spefific instaces with the cli argument you still can do.

If you opti-in create them automatically DS would just execute a new DS instance with the cli parameter for a new instance with an automatic generated instance name, following a naming schema. Should be hopefully not to hard to implement.

. And of course if it was on-the-fly random it would lose configuration settinsg that you might want to keep.

I don't get his. Accorinding to the latest closed channel change logs, DS would copy per default all settings from the default/main instance. Which is a very good thing to keep the instances in sync. So where you you loose a configuration?

I meant changes made in the auto-named instance - unless the shortcut of a deliberately named instance was edited to copy them.

Ivy said:

gerster said:

Ivy said:

The versions of daz I have now 4.5 up to 4.12.0.35  can all be loaded as multi instances with no issue of daz.  so until DEV team get the development done and give us a option so we can once again use more than 1 instance of daz at a time i am not upgrading my daz studio.   I suggest other user that need this multi instance function also hold off on getting daz 4.12.1.16  the improvements to me were not so noticeably great that it would make any difference on upgrading from 4.12.0.35,  which so far other than the optix prime being disabled errors, has not given me any trouble using it for my needs.  I did install and try 4.12.1.16 , So that is why I say the improvements are not all that noticeable or worth the upgrade to be limited to one instance of studio.  So I uninstalled 4.12.1.16 and did a clean reinstalled 4.12.0.35  and I still have other daz's like daz4.11 and 4.10 installed as well so I am good to go

that is my 2 cents

With the latest private beta it's possible (according to the changelog) to create as many instances as you like. But you have to open each instance with an special cli argument containing a unique instance name.

That means that you have to create 5 Daz desktop symbols if you want to work with 5 instances.

I hope they add an option that these named instances will be created automatically, than the behavoir would be more or less like in 4.12.0

I've been following the change log.  and I am glad to see they are working on a solution.  its to bad they broke it in the first place. so I'll still wait a while for the bugs to be worked out

It is, as far as Daz is concerned, fixing something that was broken - as witness the support calls from people for whom running two instances has caused issues. People who post to these threads probably are not representative of those users. The work being done will allow people who want multiple instances to have them, while protecting others from accidentally damaging things. (Of course, some of us are going to have to learn not to keep typing isntance first.)

Is that Daz's official statement on the issue? Because earlier you stated that was supposition, making this speculation as fact. You gotta play by the rules! Whether advertised or not Studio has had instances for what, 20 years? I rather think they could have waited a little longer. Removing instances entirely is not a fix, regardless of what the intention may have been. It would make sense to have this totally worked out before giving it to the public. It should have stayed in private builds.

Forum users may or may not be a vocal minority, but I would be willing to bet they are probably the most dedicated customers, and more likely to spend more as a result.

Rob does pass us information, though the words are not straight from the horse's mouth and I do sometimes mis-understand the point. The posts were informed, but not holy writ.

Richard Haseltine

Ivy said:

in my opinin  I believe the the issue people have with DS and the Dev team tries to accommodate for everyone usages . But the fact is every user has a different computer and directory set ups and not all PC and directories are created equal .some people have very robust machines other don't some of use have many external hard drive some of us don;t etc.   Since the day I started with DS I could always run 3 or 4 copies of studio all at the same time I have done this for years . its one of the reasons for accomplishing animation with DS and necessary for my animation work flow.  Then all of a sudden I can no longer run more than one copy of studio at a time.  That means it was broke to fix a problem some people were having but on the other hand many many other were not and were like me using multi open copies of ds

Truly I do believe  the biggest problem lies that every DS user has a different computer & content drive set up set. &  not all users have the same hardware and OS ,   Example My dual cpu system is different from your's single cpu unit in hardware set up and I am positive my content directories are not set up like yours. t hose differences are why some folks can run more than 1 instances while others can't  , you see my point. not everyone system is the same But Daz Dev has now put a block in to stop all users from loading more than one copy of ds at a time to help a few users that can't run more than one copy seems like throwing the baby out with the bathwater.

I'm not sure that much of that is directly applicable to the potential issues with the current way of running multiple instances, though I would think that how the separate instances were used would be very relevant (and that si speculative interpretation of what I know, not official word).

Hurdy3D

Richard Haseltine said:

Well, either I was wrong or it isn't seen as a major issue (not that i thought it was major, just a potential niggle with the approach). But Rob was clear that the approach you had originally suggested would not work, so I'm not sure how the balance of pros and cons played out there. I don't know that I'd want to have DS start a separate instance without a by-my-leave, though, so having a shortcut for that ana short cut for a plain launch which will fail if it's already running doesn't seem an unreasonable compromise.

Yeah... I absolutly agree that my original suggestion (random name) was not a good idea (thought shortly after I wrote it, that a name schema like the auto increanment would be better).

However, propably Rob meant that the random name would be a bad idea.

nicstt

JOdel said:

Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

You can, and it is very simple to accomplish.

Keep a few backups of versions you like; I have lots, and while I'm trying out the features of ...1.16, I can revert to earlier when I need those instances back.

I could also have saved a folder with an install of earlier, if I'd wished, but I tend not to do that.

 

I'm also inclined to agree with Outrider42, if a bug has been allowed to exist, and folks to use it for so long - particularly without being advised officially somewhere that is easy to find (presuming this is the case), then folks are entitled to think of it as a feature; it doesn't matter if its accidental or deliberate, it is still a feature.

RayDAnt

Galaxy said:

While render in progress I don't consider to run anothe program either another Daz studio instances or something else. I don't do multitasking like this but I like to minimize lot of apps for quick access one after another. By the way this consideration does not apply for mini super computers some people have. 

Yeah, my system would probably count in your mind as a mini super computer (+1 watercooled Titan RTX and counting.) Hence my annoyance at the apparently arbitrary limitation. But it's a 4th/5th world problem so I can't really complain. Too much.

Richard Haseltine

gerster said:

Richard Haseltine said:

Well, either I was wrong or it isn't seen as a major issue (not that i thought it was major, just a potential niggle with the approach). But Rob was clear that the approach you had originally suggested would not work, so I'm not sure how the balance of pros and cons played out there. I don't know that I'd want to have DS start a separate instance without a by-my-leave, though, so having a shortcut for that ana short cut for a plain launch which will fail if it's already running doesn't seem an unreasonable compromise.

Yeah... I absolutly agree that my original suggestion (random name) was not a good idea (thought shortly after I wrote it, that a name schema like the auto increanment would be better).

However, propably Rob meant that the random name would be a bad idea.

The problem with simply auto-incremnting is the potential for the index, and left over files in the event of an abnormal terminiation, to increase without limit. Rob had already considered these issues when planning the multi-instance system that is currently being implemented, now that the first Public Build for the 4.12.1 cycle has tested the principles of the blocking of identically named instances. To quote:

...the solution I was implementing addressed those specific issues (and others); patterned naming addresses the inability to track the randomness, automatic incrementation addresses the potential collision of names, gap-filling of incrementation addresses the run-away nature of "next!" and part of the pollution through abandonment issue, and automatic deletion on close (using another configurable CLI option still being implemented) addresses the other side of pollution through abandonment (to the degree that it can given a potential to crash).

Richard Haseltine

nicstt said:

JOdel said:

Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

You can, and it is very simple to accomplish.

Keep a few backups of versions you like; I have lots, and while I'm trying out the features of ...1.16, I can revert to earlier when I need those instances back.

I could also have saved a folder with an install of earlier, if I'd wished, but I tend not to do that.

 

I'm also inclined to agree with Outrider42, if a bug has been allowed to exist, and folks to use it for so long - particularly without being advised officially somewhere that is easy to find (presuming this is the case), then folks are entitled to think of it as a feature; it doesn't matter if its accidental or deliberate, it is still a feature.

The way in which multi-instances were working was a bug, it causes issues. It has been fixed (not allowing multiple instances of the same name to run) and the ability is now being implemented as a real feature, that allows people to work in as many concurrent isntances of DS as their system supports but which avoids the negative impact of the unintended approach. The new version of the feature is not yet publicly available, but the change log shows that it is coming and how it is working (albeit not everything has yet been implemented, and so the chnage log doesn't tell the full story).

RayDAnt

Richard Haseltine said:

The way in which multi-instances were working was a bug,

Multi instancing of processes is a purposeful default feature of modern operating systems like Windows and OS X. Daz Studio's compatibility with this feature may have been extremely buggy in the past (due mostly to inattention), but that doesn't make the feature itself a bug.

JOdel

Richard Haseltine said:

nicstt said:

JOdel said:

Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

You can, and it is very simple to accomplish.

Keep a few backups of versions you like; I have lots, and while I'm trying out the features of ...1.16, I can revert to earlier when I need those instances back.

I could also have saved a folder with an install of earlier, if I'd wished, but I tend not to do that.

 

I'm also inclined to agree with Outrider42, if a bug has been allowed to exist, and folks to use it for so long - particularly without being advised officially somewhere that is easy to find (presuming this is the case), then folks are entitled to think of it as a feature; it doesn't matter if its accidental or deliberate, it is still a feature.

The way in which multi-instances were working was a bug, it causes issues. It has been fixed (not allowing multiple instances of the same name to run) and the ability is now being implemented as a real feature, that allows people to work in as many concurrent isntances of DS as their system supports but which avoids the negative impact of the unintended approach. The new version of the feature is not yet publicly available, but the change log shows that it is coming and how it is working (albeit not everything has yet been implemented, and so the chnage log doesn't tell the full story).

I am assuming that manually naming the program icon DAZStudio4.12, DAZStudi4.12.1 would count as separate names? Yeah, sure, I can do that.

Richard Haseltine

JOdel said:

Richard Haseltine said:

nicstt said:

JOdel said:

Al I want to do is have more than one version of Studio installed on my machine, so that if something turns out to be broken in one of them, I can step back to a version where it isn't. I don't care how much RAM I've got, I'm not going to be running two versions of Studio at the same time.

Case in point, which I stumbled over this morning and I went into in the relevant thread. On my iMac it turns out that the release version of 4.12.0.86 is broken and cannot recognize an .obj file to import it. Neither can 4.11.0.383. I had to step back to 4.10.0.123 befoe an .obj file wasn't greyed out in the directory list.

I'm given to understand that this may be a Catalina thing, but I haven't upgraded to Catalina. I'm being bitten by it in Mojave. 

I'll go and file a ticket if it will accept one without an order #, since this is the program, not a bit of purchased content.

You can, and it is very simple to accomplish.

Keep a few backups of versions you like; I have lots, and while I'm trying out the features of ...1.16, I can revert to earlier when I need those instances back.

I could also have saved a folder with an install of earlier, if I'd wished, but I tend not to do that.

 

I'm also inclined to agree with Outrider42, if a bug has been allowed to exist, and folks to use it for so long - particularly without being advised officially somewhere that is easy to find (presuming this is the case), then folks are entitled to think of it as a feature; it doesn't matter if its accidental or deliberate, it is still a feature.

The way in which multi-instances were working was a bug, it causes issues. It has been fixed (not allowing multiple instances of the same name to run) and the ability is now being implemented as a real feature, that allows people to work in as many concurrent isntances of DS as their system supports but which avoids the negative impact of the unintended approach. The new version of the feature is not yet publicly available, but the change log shows that it is coming and how it is working (albeit not everything has yet been implemented, and so the chnage log doesn't tell the full story).

I am assuming that manually naming the program icon DAZStudio4.12, DAZStudi4.12.1 would count as separate names? Yeah, sure, I can do that.

No, it wouldn't - unless you also added the command line switch listed in the change log to the modified shortcuts.

RayDAnt said:

Richard Haseltine said:

The way in which multi-instances were working was a bug,

Multi instancing of processes is a purposeful default feature of modern operating systems like Windows and OS X. Daz Studio's compatibility with this feature may have been extremely buggy in the past (due mostly to inattention), but that doesn't make the feature itself a bug.

I am told that it is the default on MacOS is to have applications be single instance, it requires a terminal command to launch a second instance. In any event, DS will be able to run mutliple instances - safely, unlike the current situation - once all the pieces are available in a public build.

Hurdy3D

Richard Haseltine said:

The problem with simply auto-incremnting is the potential for the index, and left over files in the event of an abnormal terminiation, to increase without limit. Rob had already considered these issues when planning the multi-instance system that is currently being implemented, now that the first Public Build for the 4.12.1 cycle has tested the principles of the blocking of identically named instances. To quote:

...the solution I was implementing addressed those specific issues (and others); patterned naming addresses the inability to track the randomness, automatic incrementation addresses the potential collision of names, gap-filling of incrementation addresses the run-away nature of "next!" and part of the pollution through abandonment issue, and automatic deletion on close (using another configurable CLI option still being implemented) addresses the other side of pollution through abandonment (to the degree that it can given a potential to crash).

hm... does this mean if DS crashed the files of the instance are not deleted?

My expection would be that the auto increment feature would check just the opened instances and not the files and would just delete/overwrite the files of old instances, if there's a leftover.
 

Example

I create the instances foobar-1, foobar-2, foobar-3 before every case.

Case 1:

Close foobar-1, foobar-2, foobar-3

Open a new instance.

Expected result: The instance name would be foobar-1

Case 2:

Close  foobar-2,

Open a new instance.

Expected result: The instance name would be foobar-2

Case 3:

foobar-3 crashes

Open a new instance.

Expected result: DS detected that foobar-1 and foobar-2 are running, so the instance name would be foobar-3. But from the crashed foobar-3 the old files still exists. So it's deleting them and copies the latest file from the "main" instance to foobar-3 and creates the foobar-3 instance.

Richard Haseltine

gerster said:

Richard Haseltine said:

The problem with simply auto-incremnting is the potential for the index, and left over files in the event of an abnormal terminiation, to increase without limit. Rob had already considered these issues when planning the multi-instance system that is currently being implemented, now that the first Public Build for the 4.12.1 cycle has tested the principles of the blocking of identically named instances. To quote:

...the solution I was implementing addressed those specific issues (and others); patterned naming addresses the inability to track the randomness, automatic incrementation addresses the potential collision of names, gap-filling of incrementation addresses the run-away nature of "next!" and part of the pollution through abandonment issue, and automatic deletion on close (using another configurable CLI option still being implemented) addresses the other side of pollution through abandonment (to the degree that it can given a potential to crash).

hm... does this mean if DS crashed the files of the instance are not deleted?

My expection would be that the auto increment feature would check just the opened instances and not the files and would just delete/overwrite the files of old instances, if there's a leftover.
 

Example

I create the instances foobar-1, foobar-2, foobar-3 before every case.

Case 1:

Close foobar-1, foobar-2, foobar-3

Open a new instance.

Expected result: The instance name would be foobar-1

Case 2:

Close  foobar-2,

Open a new instance.

Expected result: The instance name would be foobar-2

Case 3:

foobar-3 crashes

Open a new instance.

Expected result: DS detected that foobar-1 and foobar-2 are running, so the instance name would be foobar-3. But from the crashed foobar-3 the old files still exists. So it's deleting them and copies the latest file from the "main" instance to foobar-3 and creates the foobar-3 instance.

I think this is the design but I am not certain how Case 3 would be handled

Ivy

Richard Haseltine said:

the ability is now being implemented as a real feature, that allows people to work in as many concurrent isntances of DS as their system supports but which avoids the negative impact of the unintended approach. The new version of the feature is not yet publicly available, but the change log shows that it is coming and how it is working (albeit not everything has yet been implemented, and so the chnage log doesn't tell the full story).

Nods* I understand your comment Richard there is a fix in the works. , I hope you didn't think I was angry at you personally for this fix/change/instance issue.   I know you do not make decisions on this stuff you only have to deal with thre backlash.  so I apologize if i came across harsh or attacking you. I can be very passionate about my work flow being interrupted  and this limited to 1 copy running at a time is a huge inconvenience..   I will keep a wait and see attitude to see what the fixes will be.  until then I'll keep what i got installed.

outrider42

If Daz is going about fixing this, that is great, and it seems to be what is happening. And it looks like instances will work better than they did before, that sounds fantastic...

But all of this could have been avoided if only Daz was just a bit more forthcoming with their plans. Like has been well stated, using multiple instances is a huge part of our workflow. When that "feature" got taken away, with absolutely no warning nor any discussion of a plan to bring it back, users are going to freak out. This should have been anticipated, and a plan of action should been given in the patch notes to start with.

Really, that's about all they ever had to do. We often see patch notes describe why a feature is changed, where that feature may be going or that its replacement is in development. Daz failed to do this. The only thing in the patch notes was about concerns for performance and stability. There was no mention about ever bringing instances back, and that is what got people freaked out. One simple sentence in the patch notes stating they had plans to have instances would have helped prevent all of this confusion. Daz would not even tell me what plans they had in their response to my support ticket. I got a boiler plate message that didn't tell me anything, what's the deal?

Why the secrecy?

Why do we have to beg for information like this? Why can't Daz come out and tell us what they are doing, like they did with Genesis 9? You do not need to offer some concrete statement like "This will be done on X date!" Just a statement that you are working on it would be quite nice. Something, anything, would be better than just pulling instances out like they did. Users don't like that.

Instead, we got a 5 page forum thread of users who quite rightfully upset over the situation asking for an explanation, and what the heck the plan was. I posted this thread on the 16th. Some of this information has only come to light in the past couple of days, a full week later. And furthermore a lot of the info is only coming from the private build notes. No statements.

We are not asking for your tax returns. Just some simple transparency for things like this so we don't have to freak out over what our application is doing. People are heavily invested in Studio. It is a passion, a hobby, and for some, a job. With that passion, comes responses like what we've seen. Everybody in this thread wants to see Daz succeed and be great, and any heated remarks are made because of our passion for this art form. So it would be nice if Daz could tell us what they have cooking once in a while, which would end any rampant speculation on such subjects.

Is that too much to ask?

Zai

Richard Haseltine said:

I am told that it is the default on MacOS is to have applications be single instance, it requires a terminal command to launch a second instance. In any event, DS will be able to run mutliple instances - safely, unlike the current situation - once all the pieces are available in a public build.

Yes..Daz is the only program I have EVER had to use a command line to run multiple instances of since pretty much every other program just opens extra documents, etc. A new "instance" isn't required. Never had the need in any other program, although I guess with 3D type programs that's different.

Richard Haseltine

Zai said:

Richard Haseltine said:

I am told that it is the default on MacOS is to have applications be single instance, it requires a terminal command to launch a second instance. In any event, DS will be able to run mutliple instances - safely, unlike the current situation - once all the pieces are available in a public build.

Yes..Daz is the only program I have EVER had to use a command line to run multiple instances of since pretty much every other program just opens extra documents, etc. A new "instance" isn't required. Never had the need in any other program, although I guess with 3D type programs that's different.

A lot are MDI, though - they can open multuiple documents within a single instance. All my office apps, pretty much all of my image manipulation apps (not sure about Rebelle), illustration apps, DTP apps, and even my main modeller (modo) work that way.

RayDAnt

outrider42 said:

Is that too much to ask?

If DAZ had done this in a General Release then I'd totally agree with you. But they didn't. They did it in a Beta release. And Beta releases are - by definition - experimental/featureset fluid. DAZ has never released a full version of DAZ Studio which doesn't allow multi instancing.

Daywalker Designs

RayDAnt said:

outrider42 said:

Is that too much to ask?

If DAZ had done this in a General Release then I'd totally agree with you. But they didn't. They did it in a Beta release. And Beta releases are - by definition - experimental/featureset fluid. DAZ has never released a full version of DAZ Studio which doesn't allow multi instancing.

I'm not sure that was by design, to be honest. It works, and for a lot of people it doesn't seem to create issues, but it wasn't what I would personally consider proper multi-instancing. Having support for separate temporary directories and named instances is much better, especially if they can isolate those instances in completely separate memory spaces so that if one instance crashes, it doesn't take others down or corrupt files in them.

JOdel

Re-asking the basic question here: Does this mean that multiple versions of Studio cannot be installed, or that they cannot be opened *at the same time* on the same machine? So long as I can keep an earlier version available in case of the kind of problems with broken features that I ran into last week, I'll be satisfied. I already have a perfectly good work-around for installing without overwriting the earlier version. As long as I can launch them individually I'm not losing anything that's going to be missed.

Other people's milage may vary.

scorpio

JOdel said:

Re-asking the basic question here: Does this mean that multiple versions of Studio cannot be installed, or that they cannot be opened *at the same time* on the same machine? So long as I can keep an earlier version available in case of the kind of problems with broken features that I ran into last week, I'll be satisfied. I already have a perfectly good work-around for installing without overwriting the earlier version. As long as I can launch them individually I'm not losing anything that's going to be missed.

Other people's milage may vary.

As far as I'm aware they are just talking about haveing several instancese of DS open at the same time, not different versions. It should still be possible to have and old version and a new version(for example) installed, otherwise its going to be tricky with the betas.

Richard Haseltine

scorpio said:

JOdel said:

Re-asking the basic question here: Does this mean that multiple versions of Studio cannot be installed, or that they cannot be opened *at the same time* on the same machine? So long as I can keep an earlier version available in case of the kind of problems with broken features that I ran into last week, I'll be satisfied. I already have a perfectly good work-around for installing without overwriting the earlier version. As long as I can launch them individually I'm not losing anything that's going to be missed.

Other people's milage may vary.

As far as I'm aware they are just talking about haveing several instancese of DS open at the same time, not different versions. It should still be possible to have and old version and a new version(for example) installed, otherwise its going to be tricky with the betas.

That's right, it's instances of the same version not different versions, that are being tidied up/made supported.

Richard Haseltine

Daywalker Designs said:

RayDAnt said:

outrider42 said:

Is that too much to ask?

If DAZ had done this in a General Release then I'd totally agree with you. But they didn't. They did it in a Beta release. And Beta releases are - by definition - experimental/featureset fluid. DAZ has never released a full version of DAZ Studio which doesn't allow multi instancing.

 

I'm not sure that was by design, to be honest. It works, and for a lot of people it doesn't seem to create issues, but it wasn't what I would personally consider proper multi-instancing. Having support for separate temporary directories and named instances is much better, especially if they can isolate those instances in completely separate memory spaces so that if one instance crashes, it doesn't take others down or corrupt files in them.

Right.

outrider42

RayDAnt said:

outrider42 said:

Is that too much to ask?

If DAZ had done this in a General Release then I'd totally agree with you. But they didn't. They did it in a Beta release. And Beta releases are - by definition - experimental/featureset fluid. DAZ has never released a full version of DAZ Studio which doesn't allow multi instancing.

That depends. The beta can be far, far ahead of the general release. We went a solid 2 years on 4.10, and for a time the general release did not support Turing RTX cards at all, as you well know. Even now the beta has already added several advancements over the general release. Moreover, even Daz's own have recommended using the beta at times, including for RTX owners during that launch period. We also had that big discussion of 'what constitutes a beta' a while back. So a lot of people are using the beta as their main app. Its also logical to assume that the people who are considered power users would be using the beta for its latest features. Power users are probably more likely to be the ones using multiple instances. I am making this assumption, but I think its logical there is a connection there between them.

So with those points in mind, I don't think it was a good idea to unleash a non instanced version of Studio to the public in any form. It should have stayed in private builds until it was fully worked out. IMO the people more likely to be using instances are the same ones who are more likely to be using the beta. So they are the ones most effected by any changes to instances.

Richard Haseltine

outrider42 said:

RayDAnt said:

outrider42 said:

Is that too much to ask?

If DAZ had done this in a General Release then I'd totally agree with you. But they didn't. They did it in a Beta release. And Beta releases are - by definition - experimental/featureset fluid. DAZ has never released a full version of DAZ Studio which doesn't allow multi instancing.

 

That depends. The beta can be far, far ahead of the general release. We went a solid 2 years on 4.10, and for a time the general release did not support Turing RTX cards at all, as you well know. Even now the beta has already added several advancements over the general release. Moreover, even Daz's own have recommended using the beta at times, including for RTX owners during that launch period. We also had that big discussion of 'what constitutes a beta' a while back. So a lot of people are using the beta as their main app. Its also logical to assume that the people who are considered power users would be using the beta for its latest features. Power users are probably more likely to be the ones using multiple instances. I am making this assumption, but I think its logical there is a connection there between them.

 

So with those points in mind, I don't think it was a good idea to unleash a non instanced version of Studio to the public in any form. It should have stayed in private builds until it was fully worked out. IMO the people more likely to be using instances are the same ones who are more likely to be using the beta. So they are the ones most effected by any changes to instances.

The problem with limiting the availablity of the version that checked for other running instances is that it's a siginificant chnage, it really needs more testing on a greater variety of systems than a private test group is likely to permit. The chnage was listed in the highlights thread, so people had a chance to see it and not download the new beta if it presented an insuperable obstacle.

outrider42

Well then, I think the test is complete! <.<

RayDAnt

sylvie1998 said:

The idea with command line option and named instances is terrible since it does not allow for quick and easy launch of an additional instance when you need one because you first need to copy and edit the shortcut, not to mention that you need to remember which ones you launched already and which you did not.

Software should manage things like this automatically, instead of burdening its users with manual and repetitive tasks.

See this post.

Can't quite personally fathom why they felt going with this seemingly circuitous CLI route is worth the effort (it does impart greater functionality for advanced users than simply going off of process ID would, but functionality useful for accomplishing what exactly?) But according to the latest changelogs this new method of multi instancing is already user transparent.