Delay pan by Hk1020 · Pull Request #1151 · jamulussoftware/jamulus

Hk1020 · 2021-02-28T23:22:25Z

See #567. This reestablished and aligned #332 with current development.

ann0see

Can't say too much here, but have a look at my comments. Also please verify the style.

ann0see · 2021-03-01T06:05:43Z

src/main.cpp

+        }
+
+        // Enable delayed panning on startup ----------------------------------------
+        if ( GetFlagArgument ( argv,


Why do we need two cli flags? Wouldn't one be enough?

Yes one would be enough. I realized this too after I made the PR. Two options would be useful should we change the default in a later release. We’d still need to decide on the default. I’d like on as default in which case you need the —nodelaypan option. With off as default you want the -P/—delayedpan option.

If switching it on means more processing power, I would not enable it by default (there is and was a lot going on with optimizing server performance and adding something which needs more power is counter productive). You can always switch it on of course.

I remember that Volker mentioned that this delay pan might not be a better experience for everybody, for example bands. So I also wouldn't enable it per default.

Maybe someone with a band could try it?

ann0see · 2021-03-01T06:06:52Z

src/server.cpp

+                            }
+                            else
+                                vecfIntermProcBuf[k + 1] += vecsData[iRpan];
+                            ;


What's this for?

What do you mean? The spurious semicolon? That can go of course.

How would I have to fix this? Push another commit?

And are the lone else's without braces ok?

I would use a force push. Concerning the else I don't think that's the style used overall. But since we're getting improved code, I'd wait for this before working on more here.

Hk1020

I don’t know what I did here with _review _

Hk1020 · 2021-03-01T08:46:17Z

src/server.cpp

+                            }
+                            else
+                                vecfIntermProcBuf[k + 1] += vecsData[iRpan];
+                            ;


What do you mean? The spurious semicolon? That can go of course.

DominikSchaller · 2021-03-01T09:48:37Z

Hello, I'm in contact with Detlef Hennings who wrote the original code. He improved his code since June 2020 and can provide an updated version in a couple days. It's up to you if you want to merge this now and then do a new pull request when we get the revised version, or if you wait for this update.

I am using this delay pan feature for a couple weeks now with my chorus, and it makes a real difference! I'm glad it is finally finding its way into the main branch.

ann0see · 2021-03-01T11:16:10Z

or if you wait for this update.

I'd wait for the update then. No need to rush this.

DominikSchaller · 2021-03-02T00:10:22Z

@Hk1020 This is the latest version of the code of Detlef which he just sent me. I have no idea of the content, but I think you should be able to detect any changes he made and determine if they are good. I used the compiled version of the code with my chorus for a couple weeks now, we had no bugs, the server was running stable, and the sound was good.
Jamulus_360_delpan_modified-sources_009f.zip

Hk1020 · 2021-03-02T07:43:36Z

@DominikSchaller Excellent, I‘ll have a look later, thank you (and Detlef Hennings).

ann0see · 2021-03-02T18:52:53Z

Can we close this and open a new PR once the new code is available?

DominikSchaller · 2021-03-02T18:54:49Z

Can we close this and open a new PR once the new code is available?

The new code is already available, I posted it here last night.

Hk1020 · 2021-03-02T18:56:24Z

Can we close this and open a new PR once the new code is available?

I am looking at the new version right now and compare it to this one.

Hk1020 · 2021-03-02T18:57:48Z

I'd like to keep it here.

ann0see · 2021-03-02T20:45:08Z

The new code is already available, I posted it here last night.

Ok. Thanks. Just saw it (again).

Hk1020 · 2021-03-02T23:30:35Z

I'm done with analyzing the code. There is no functional difference in the actual panning code except one cut/paste error I introduced. Everything else is just handling of how to turn it on - the new version has fewer options - and a lot of commented code. I'll prepare a new version soon.

Hk1020 · 2021-03-03T22:52:35Z

I've updated the PR. Where is a good place to discuss the code? Here or in an issue (#567)?

ann0see · 2021-03-04T06:20:10Z

Probably here. You can start reviewing it again

ann0see · 2021-03-04T12:19:12Z

src/server.cpp

            const float             fGain    = vecvecfGains[iChanCnt][j];
-            const float             fPan     = vecvecfPannings[iChanCnt][j];
+            const float             fPan     = bDelayPan ? 0.5f : vecvecfPannings[iChanCnt][j];
+            const int iPanDel = lround( (float)(2 * maxPanDelay - 2) * (vecvecfPannings[iChanCnt][j] - 0.5f) );


I'm not sure about the style here.

Suggested change

const int iPanDel = lround( (float)(2 * maxPanDelay - 2) * (vecvecfPannings[iChanCnt][j] - 0.5f) );

const int iPanDel = lround( (float)( 2 * maxPanDelay - 2 ) * ( vecvecfPannings[iChanCnt][j] - 0.5f ) );

Does this line calculate the delay between left and right? Sorry if this is obvious ;-).

I am not sure. There are more places where you could save on temporary variables. So far I haven't really understood what's been done here.

Hmm. Before merging this, we (or at least one/two of the main developers) have to be exactly sure what each line does (and comment it). If anything goes wrong it should be possible to debug it.

Having investigated the code more iPanDel is the position and the delay happens later by adding iServerFrameSizeSamples to one of the two channels. Correct me if I’m wrong.

We should also check how maxPanDelay is set. Might be a simple #define.

ann0see · 2021-03-04T12:20:35Z

src/server.cpp

+                                iLpan = iLpan + iServerFrameSizeSamples; //
+                                vecfIntermProcBuf[k] += vecsData2[iLpan];
+                            }
+                            else


I think this doesn't match the style (the else)

ann0see · 2021-03-04T12:21:31Z

src/server.cpp


        // we always use stereo audio buffers (which is the worst case)
        vecvecsData[i].Init ( 2 /* stereo */ * DOUBLE_SYSTEM_FRAME_SIZE_SAMPLES /* worst case buffer size */ );
+        vecvecsData2[i].Init ( 2 /* stereo */ * DOUBLE_SYSTEM_FRAME_SIZE_SAMPLES /* worst case buffer size */ );


Is this also needed if delayed panning is off? If not, do we need to initialize it (does it have any performance impact)? (also applies to line 345).

Detlef Hennings is working on being able to operate the delay panning in different modes. This is about the distribution of the singers in the virtual space.

Therefore it would be good to keep the parameter '-P panmode' free for this and similar developments and to use for delay panning only --DelayPan (or similar) for delay panning.

Furthermore, delay panning is so important for singers that it should be possible to activate it via a checkbox.

Furthermore, delay panning is so important for singers that it should be possible to activate it via a checkbox.

I think this is already part of this PR: https://github.com/jamulussoftware/jamulus/blob/0c6b3fbfc261b1b078bbd43ed939107deb07132e/src/serverdlgbase.ui

Furthermore, delay panning is so important for singers that it should be possible to activate it via a checkbox.

I think this is already part of this PR: https://github.com/jamulussoftware/jamulus/blob/0c6b3fbfc261b1b078bbd43ed939107deb07132e/src/serverdlgbase.ui

Right now this is a server setting. I'd also prefer this to be a client setting but it isn't yet. If it is we wouldn't need the command line option.

This would probably need a new protocol message.

Thought about it once more: it is a good idea after all to make this a client setting. Thanks for asking!

There would need to be:

a message from the server saying "I support delay pan if you want it"

a message from the client saying "I would like delay pan"

a client method to send the message

a clientUI mechanism to request the feature only if the server supports it (which would need to take server version and the specific message into account). (I'm not sure if this should be in settings, as it's a user preference, or a on the server mixer, as the choice might vary depending on the jam session.)

I also think maybe get the server support finished and released "as is" before adding the client side. I definitely think it's worth having, though.

As far as our 9 month experience with vocal ensembles and choirs goes, once the participants have heard the impression of delay panning, they would never want to go back to volume panning. And with acoustic instrumentalists it seems to be similar. I suppose that the preference will mainly depend on the music style. For instance, choir and classical music servers could preferably use delay panning and rock music servers might use volume panning (well, I assume that). Then, at least for a first implementation, the pan type decision can be made on the server side. And public servers may announce which panning type they provide.
If really required, an override option from the client side could be added in a later Jamulus version. But this would complicate server algorithms, because then they need to handle mixed delay and volume panning processing.

I‘d also like to get this done. The sooner the better. People would benefit immediately. The client part can come later and this should go out right away (3.7.0). But it is not on me to decide. I too can’t imagine anyone wanting to go back to volume panning.

I‘d been entertaining the idea to provide a client setting in a later PR. The grounds are laid and there isn’t much to add to the server logic except the protocol bit. Mixing is per client already so we only need to make bDelayPan a vector, similar to fPan.

The problem is, because we want to be certain about the quality and fully understand operation of the code that goes into a release, every additional feature causes further delay in the release of 3.7.0, which already is later than we would have liked. That is not to express any doubt about the code quality or its usefulness, it just takes time.

It will definitely be fully reviewed for inclusion in 3.7.1, and hopefully that release will not be too far into the future.

ann0see · 2021-03-04T17:57:18Z

I'll run this code on my server and will look for feedback from my choir. I hope that it doesn't require more processing power.

Edit: before this gets merged, the commits should be attributed to Detlef Hennings.

Hk1020 · 2021-03-04T20:51:50Z

Probably here. You can start reviewing it again

Ok. I first wanted to say that this code is not verbatim of what we got in the zip file from Detlef Hennings. I have another branch locally where I traced everything. Do you somehow want it?

This here is based on what Volker did in #332. The only real change is the cli option. The rest is adapting it to master. I compared it to Detlef Hennings' version, which looks quite a bit of work in progress. I compared everything and verified that they are functionally equivalent. There is certainly potential to streamline the code.

Hk1020 · 2021-03-04T21:09:51Z

I'll run this code on my server and will look for feedback from my choir.

So will I.

I hope that it doesn't require more processing power.

From a cursory check via htop on my Pi4 I couldn't see any difference. But I've also been wondering about this optimization in line 1230 (don't know how to directly link here):

if ( ( fGainL == 1.0f ) && ( fGainR == 1.0f ) ) {

This has been there before and leads to a lot of code duplication, especially now. Only to save one multiplication in the end. This if branch is dead and broken in the zip file version.

Edit: before this gets merged, the commits should be attributed to Detlef Hennings.

Do you mean in some comment or somewhere else?

Hk1020 · 2021-03-04T21:29:06Z

Since I've never done a PR before am I supposed to do something with these comments? What does this Resolve comments do?

ann0see · 2021-03-04T22:18:15Z

Edit: before this gets merged, the commits should be attributed to Detlef Hennings.
Do you mean in some comment or somewhere else?

I‘d do it in the commit message: https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors

am I supposed to do something with these comments?

No. Just leave them open.

Hk1020 · 2021-03-04T23:38:41Z

src/server.cpp

+            const int iPanDel = lround( (float)(2 * maxPanDelay - 2) * (vecvecfPannings[iChanCnt][j] - 0.5f) );
+            const int iPanDelL = ( iPanDel > 0 ) ? iPanDel : 0;
+            const int iPanDelR = ( iPanDel < 0 ) ? -iPanDel : 0;



We now have with bDelayPan = true:

const float fGain = vecvecfGains[iChanCnt][j]; const float fPan = bDelayPan ? 0.5f : vecvecfPannings[iChanCnt][j];

fPan = 0.5

const int iPanDel = lround( (float)(2 * maxPanDelay - 2) * (vecvecfPannings[iChanCnt][j] - 0.5f) ); const int iPanDelL = ( iPanDel > 0 ) ? iPanDel : 0; const int iPanDelR = ( iPanDel < 0 ) ? -iPanDel : 0; const float fGainL = MathUtils::GetLeftPan ( fPan, false ) * fGain;

GetLeftPan is 1 for fPan = 0.5 (see util.h), i.e, fGainL = fGain

const float fGainR = MathUtils::GetRightPan ( fPan, false ) * fGain;

Same here, fGainR = fGain.

~~So we could do away with fGainL and fGainR completely and just use fGain (if bDelayPan==true). Or what am I missing?~~

~~If I am right the rest of the code could shrink a lot.~~

pljones · 2021-03-05T08:26:46Z

src/server.h

 * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
 *
 \******************************************************************************/
+//******************************************************************************************


This goes in the Changelog, not the source code.

softins · 2021-03-05T09:49:43Z

I'll review this and try it out soon.

DetlefHennings · 2021-03-05T18:45:11Z

Hello Everybody!

I'm the author of the original delay panning code for Jamulus, and I would like to mention, that this code has been tested since June 2020 and is in use by different vocal groups, choirs and and also by acoustic instrumentalists since then.
The delay pan servers were always stable and not a single bug was reported during that time. So it may be a good idea to leave the functional part of the code unchanged, even if it does not exactly comply with the coding rules of Jamulus. Please have in mind the old principle of a good design: FORM follows FUNCTION (not the other way).
Thank you !

PS
In the client list on the server GUI I added a column 'channels'. Mainly in larger groups like choirs this is helpful to detect if any clients use their Jamuli in mono mode and cannot take advantage of the delay panning.
For quick 'not connected' debugging during a session it may also be useful to show the server port number on the GUI.

PPS
I'm visiting github only occasionally. In case of questions contacting me via mail may be faster (address in my latest source files)

Co-authored-by: Detlef Hennings <[email protected]>

Hk1020 · 2021-03-22T20:40:48Z

Meanwhile, could you rebase/solve the Changelog conflict @Hk1020? Thanks!

Done.

softins

OK, I have read through the code, and compared with the branch point, although I haven't tried running it. I understand what it's doing, and it looks like it should work as intended. I think some of the code could be made more efficient, but compiler optimisation will probably help. It might be worth revisiting that if we see a significant difference in performance, but for now, happy to approve.

ann0see · 2021-03-23T12:35:49Z

@gilgongo I think this needs to be documented on the changes branch in the documentation. @DetlefHennings can you give a short description for the documentation so we can add it here: https://jamulus.io/wiki/Command-Line-Options

DetlefHennings · 2021-03-23T13:26:25Z

The short description can be:
--delaypan Switches the server to 'delay panning' mode instead of the default 'volume panning' mode.

A bit more detailed description (elsewhere) can be:
When using a Jamulus server in 'delay panning' mode, the musicians listening under their headphones can hear each other outside of their heads like in a physical meeting. The heard directions to the others can be controlled by the respective PAN knobs. To achieve this result, all client Jamuli should be set to 'mono in / stereo out'.

Hk1020 · 2021-03-23T15:18:26Z

Although this has now been merged - thank you - it seems the conversation above #1151 (comment) about defaults got lost. I’d still like to raise it again.

softins · 2021-03-23T22:45:37Z

Although this has now been merged - thank you - it seems the conversation above #1151 (comment) about defaults got lost. I’d still like to raise it again.

Ok, see below

Ok, I've just fixed that and use delaypan/delay panning throughout.

I am still wondering, though, if we shouldn't make this default to on. As Detlef Hennings wrote essentially nobody would go back to volume panning once they heard delay panning and I very much agree. Especially choirs will benefit from this, so this will be a lot of people, and from my experience with helping them they struggle a lot with setting up their own server. I think most won't touch anything again as they are glad the thing works at all. They would all miss out on this if we ask them to set another option. On the other hand, those who will be annoyed by the new sound will figure out how to go back if we provide the option for it.

I understand your motivation for this, but my view is that we shouldn’t make enabled by default a new behaviour that most people have not tried out and experienced. No problem with highlighting it and promoting the benefits.

If there is a lot of positive feedback from people who have tried it, you can be sure that word will spread, and we could consider making it the default in 3.8

npostavs · 2021-03-24T02:22:27Z

Speaking as someone fairly ignorant of the details of audio tech, I'd be curious as to what the differences are. I've briefly tried this out, but I couldn't notice anything obvious (although having it controlled by command line parameter makes it more difficult to compare side-by-side).

Hk1020 · 2021-03-24T09:14:30Z

Speaking as someone fairly ignorant of the details of audio tech, I'd be curious as to what the differences are. I've briefly tried this out, but I couldn't notice anything obvious (although having it controlled by command line parameter makes it more difficult to compare side-by-side).

Actually, if you start the server with the GUI there is a checkbox to turn it on or off on the fly. It makes the difference really obvious. But not with mono! And use the pan knob. The effect is somewhat subtle.

npostavs · 2021-03-24T12:38:34Z

Oh, I was passing the option to the client instead, no wonder I didn't notice any difference. Oops! (maybe passing it to the client should give a warning though, instead of saying - starting with delay panning).

In searching for explanations/examples about it I found this youtube video which talks about "the Haas effect". Is that the same as "delay panning"?

softins · 2021-03-24T13:10:10Z

Oh, I was passing the option to the client instead, no wonder I didn't notice any difference. Oops! (maybe passing it to the client should give a warning though, instead of saying - starting with delay panning).

There are actually a lot of server-only options that do not generate a warning when given to a client, although they are then ignored. It would be good to tidy that up a bit!

Hk1020 · 2021-03-24T13:21:23Z

Oh, I was passing the option to the client instead, no wonder I didn't notice any difference. Oops! (maybe passing it to the client should give a warning though, instead of saying - starting with delay panning).

There are actually a lot of server-only options that do not generate a warning when given to a client, although they are then ignored. It would be good to tidy that up a bit!

From what I could see there isn’t any support in the current command line parsing for further dependency checking. Has to be done manually.

DetlefHennings · 2021-03-24T13:30:42Z

In searching for explanations/examples about it I found this youtube video which talks about "the Haas effect". Is that the same as "delay panning"?

Delay panning, when used with headphones, simply 'simulates' the runtime difference between the two ears depending on the horizontal angle of sound incidence (it's not the Haas effect). This relation to human hearing makes it sound so natural. BTW, the effekt is lost, when a delay pan is set exactly to center.

Hk1020 · 2021-03-24T14:53:40Z

In searching for explanations/examples about it I found this youtube video which talks about "the Haas effect". Is that the same as "delay panning"?

Delay panning, when used with headphones, simply 'simulates' the runtime difference between the two ears depending on the horizontal angle of sound incidence (it's not the Haas effect). This relation to human hearing makes it sound so natural. BTW, the effekt is lost, when a delay pan is set exactly to center.

Now you got me curious. How is this not the Haas effect (which I learned about just now)?

softins · 2021-03-24T15:30:56Z

In searching for explanations/examples about it I found this youtube video which talks about "the Haas effect". Is that the same as "delay panning"?

Delay panning, when used with headphones, simply 'simulates' the runtime difference between the two ears depending on the horizontal angle of sound incidence (it's not the Haas effect). This relation to human hearing makes it sound so natural. BTW, the effekt is lost, when a delay pan is set exactly to center.

Now you got me curious. How is this not the Haas effect (which I learned about just now)?

I just watched the video. Really interesting, and a good demonstration of delay panning. Although more than a couple of ms difference is more than the ears would naturally encounter, because sound travels through air at approximately 34cm per ms.

I then read about the Haas effect at https://en.wikipedia.org/wiki/Precedence_effect. That seems to be talking about something slightly different: hearing a sound with both ears, followed by an identical sound, again with both ears, a very short delay later (a few ms). Something like a very quick echo. It doesn't appear to be talking about why a single sound's perceived direction is because of the difference in arrival time at each ear.

So it seems the guy making the video was mistaken in calling it the Haas effect.

DominikSchaller · 2021-03-25T11:43:33Z

Thanks for merging this feature into master! This stale branch can be deleted now: https://github.com/jamulussoftware/jamulus/tree/feature_hennings_delay_pan2

ann0see · 2021-03-31T17:33:03Z

I think it's removed now

DetlefHennings · 2021-04-28T20:30:08Z

Next generation choir server

It seems that delay panning is going to be delayed (!) by introducing more and more issues into v.3.7.1, or now v.3.8.0. But meanwhile the next generation server for choirs and other acoustic music ensembles is under test.

This server arranges all clients in a circle geometry and all (delay) pans are calculated from this geometry and are set automatically. This avoids controlling a large number of pans. Individual client positions on the circle are set either by numeric input or by a pseudo random algorithm.

For testing Debian and Ubuntu beta binaries and a short explanation are available under this link.

pljones · 2021-04-28T21:09:35Z

We're in planning for release now :).

jstallkamp · 2021-05-05T07:15:07Z

Circle mode sounds awesome. It'd be great if geometry could also be controlled "by group" (without manually assigning numbers to participants' names). But that might be the/a next step, after the feature has been shown to work.

ann0see reviewed Mar 1, 2021

View reviewed changes

Hk1020 commented Mar 1, 2021

View reviewed changes

ann0see added this to the Release 3.7.0 milestone Mar 4, 2021

ann0see added the feature request Feature request label Mar 4, 2021

ann0see modified the milestones: Release 3.7.0, Release 3.7.1 Mar 4, 2021

ann0see reviewed Mar 4, 2021

View reviewed changes

ann0see requested review from pljones and softins March 4, 2021 22:23

Hk1020 commented Mar 4, 2021

View reviewed changes

pljones reviewed Mar 5, 2021

View reviewed changes

Hk1020 and others added 2 commits March 22, 2021 20:31

Column "channels" added in server GUI.

66548ee

Co-authored-by: Detlef Hennings <[email protected]>

Correct unused column.

43239ff

Hk1020 force-pushed the delay_pan branch from ffd0894 to 43239ff Compare March 22, 2021 19:32

Fixed delaypan option.

e8f5bca

pljones approved these changes Mar 23, 2021

View reviewed changes

softins approved these changes Mar 23, 2021

View reviewed changes

softins merged commit eaed4c2 into jamulussoftware:master Mar 23, 2021

ann0see mentioned this pull request Mar 23, 2021

Support delay panning in the server #332

Closed

softins mentioned this pull request Mar 24, 2021

Issue warning when server-only options are given to a client, or vice versa #1336

Closed

ann0see mentioned this pull request Mar 25, 2021

Document delay panning jamulussoftware/jamuluswebsite#389

Closed

Hk1020 deleted the delay_pan branch April 25, 2021 17:57

passing mentioned this pull request May 10, 2021

Suggestion of adding 'positional audio' of instruments or choir sections #567

Closed

	const int iPanDel = lround( (float)(2 * maxPanDelay - 2) * (vecvecfPannings[iChanCnt][j] - 0.5f) );
	const int iPanDel = lround( (float)( 2 * maxPanDelay - 2 ) * ( vecvecfPannings[iChanCnt][j] - 0.5f ) );

Comments

Conversation

Hk1020 commented Feb 28, 2021

Uh oh!

ann0see left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hk1020 Mar 1, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hk1020 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DominikSchaller commented Mar 1, 2021

Uh oh!

ann0see commented Mar 1, 2021

Uh oh!

DominikSchaller commented Mar 2, 2021

Uh oh!

Hk1020 commented Mar 2, 2021

Uh oh!

ann0see commented Mar 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DominikSchaller commented Mar 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Hk1020 commented Mar 2, 2021

Uh oh!

Hk1020 commented Mar 2, 2021

Uh oh!

ann0see commented Mar 2, 2021

Uh oh!

Hk1020 commented Mar 2, 2021

Uh oh!

Hk1020 commented Mar 3, 2021

Uh oh!

ann0see commented Mar 4, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hk1020 Mar 5, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hk1020 Mar 1, 2021 •

edited

Loading

ann0see commented Mar 2, 2021 •

edited

Loading

DominikSchaller commented Mar 2, 2021 •

edited

Loading

Hk1020 Mar 5, 2021 •

edited

Loading

Hk1020 Mar 11, 2021 •

edited

Loading

ann0see commented Mar 4, 2021 •

edited

Loading

Hk1020 commented Mar 4, 2021 •

edited

Loading

Hk1020 Mar 4, 2021 •

edited

Loading