[FIX] Project.write_json() update outputs instead of overriding them

[Gautzilla]

If a project's JSON was modified by another process while the script was running (e.g. if two transforms are run simultaneously in different jobs), the latter overwrote the former

This PR should fix it by parsing the outputs in the project's JSON and joining them with the outputs of the project in the current shell.

The only remaining thing that could be messy if if someones runs simultaneously 2 transform that have the same name: the latter might still overwrite the former, but I'm not sure what's the best way of avoiding that (other than the user not doing that mistake!)

This PR resolves #405

[coveralls]

coverage: 98.983% (+0.009%) from 98.974% — Gautzilla:fix/project-write-json into Project-OSmOSE:main

[mathieudpnt]

This worked for me as i successfully launched 13 Transforms simultenaously 🥇

Also, would be nice to have the transforms of a Project instance in alphanumerical order 👼

It would be nice to sort alphanumericaly the Transform names though

[Gautzilla]

It would be nice to sort alphanumericaly the Transform names though

For some reason you've put your finger on something fishy.

The unbearable truth about default transform names

We had let the default transform name to None, with the default audio outputs being exported in a duration_samplerate folder and the default spectral outputs being exported in a duration_samplerate/mfft_winsize_hop_linear folder.

The default None value is an issue, as running different transforms with a default name would lead to different outputs referring to a transform named None, which would be confusing.

WE should then rework the default transform name, with or without keeping the "legacy" default names of the outputs.

Here are some thoughts about it:

1: make the name mandatory

The more straightforward way to address the issue: we don't have to imagine what most people would want to name their transforms by default, they just have to name them themselves.

2: keep the "legacy" default names

We keep the idea of the legacy default names by parsing the transform specs in its name by default. IMO it has several downsides:

• We'd have to parse at least the begin timestamp, data duration, sample rate, fft specs to hope to reach a "unique" transform name for a given project, which will lead to long, unreadable (and maybe still not so unique) transform names
• This would still not be as readable as the user giving a chosen name to the transform: in the legacy version where this was not an option, it was the only way for the user to know which folder contained what outputs, but now it seems a bit outdated

3: pick an incremented ID number

One other simple way to do it is to just name the first transform 0001 by default, the next one 0002 and so on: if the user think it's unclear, they still can name the transforms as they wish.

So?

Anyways, I think I'd go for option 3 or 1, but if anyone has something better in mind I'm all open (@mathieudpnt @cazaudo @MaelleTtrt)

[mathieudpnt]

It would be nice to sort alphanumericaly the Transform names though

For some reason you've put your finger on something fishy.

The unbearable truth about default transform names

We had let the default transform name to None, with the default audio outputs being exported in a duration_samplerate folder and the default spectral outputs being exported in a duration_samplerate/mfft_winsize_hop_linear folder.

The default None value is an issue, as running different transforms with a default name would lead to different outputs referring to a transform named None, which would be confusing.

WE should then rework the default transform name, with or without keeping the "legacy" default names of the outputs.

Here are some thoughts about it:

1: make the name mandatory

The more straightforward way to address the issue: we don't have to imagine what most people would want to name their transforms by default, they just have to name them themselves.

2: keep the "legacy" default names

We keep the idea of the legacy default names by parsing the transform specs in its name by default. IMO it has several downsides:

* We'd have to parse at least the begin timestamp, data duration, sample rate, fft specs to hope to reach a "unique" transform name for a given project, which will lead to long, unreadable (and maybe still not so unique) transform names

* This would still not be as readable as the user giving a chosen name to the transform: in the legacy version where this was not an option, it was the only way for the user to know which folder contained what outputs, but now it seems a bit outdated

3: pick an incremented ID number

One other simple way to do it is to just name the first transform 0001 by default, the next one 0002 and so on: if the user think it's unclear, they still can name the transforms as they wish.

So?

Anyways, I think I'd go for option 3 or 1, but if anyone has something better in mind I'm all open (@mathieudpnt @cazaudo @MaelleTtrt)

I would vote for option 1 and make name a mandatory argument in a Transform instance. It's easy for user who like the legacy behaviour to keep it that way 👨‍🎨

[Gautzilla]

@cazaudo @MaelleTtrt If you're OK with Mathieu I'll just make the name parameter of the Transform mandatory and push!