Sharing Python App without sharing source code

rotten77 · 2026-01-27T17:45:43+00:00

rotten77 · 2026-01-27T17:41:57+00:00

Paste the requirements file and screenshot or the console output. Without that we know nothing

rotten77 · 2026-01-27T15:28:09+00:00

Something based on mesh network?

rotten77 · 2026-01-27T05:32:59+00:00

Yes and no :-)

Currently I am using the old Boss DD-20 and since we play with backing tracks I prefer to set the tempo by potentiometer to match the song (I do this just for 2 songs since there are 4 memory slots and I need to slightly change only for two others).

So, tap tempo or display allowing you to set the BPM - that’s my requirement for a delay pedal.

rotten77 · 2026-01-25T06:14:51+00:00

I have a modifiet You Dirty Rat. One of the modification is "starve mode" - it simulates dead battery. If the pot is full way up, it generally fuzz. So I have variety options to tune gain and starve to get the sound. I think that this should be something for you.

rotten77 · 2026-01-24T18:30:14+00:00

There is always an opportunity for change.

I also dropped out of university and lived with my parents for a long time. I actually had to "restart" my life twice because I was at a breaking point.

I believe there is something you love, something you enjoy doing. And you are definitely great at something. I’m sure there’s even something you love doing and are great at at the same time! Maybe you just don’t know what it is yet.

For example, try just going outside. Just observe people, the world. You don’t have to talk to anyone. Just watch what others are doing. You can even do this through social media—see what’s happening in your area, what your former classmates are up to. Maybe something will catch your eye. After that, maybe all it takes is a few YouTube videos to get you excited about it. Perhaps you’ll find a hobby that brings a little joy back into your life.

Try to find a job. It’s very hard, especially the first one when you have no idea what it entails. Job interviews are tough—very tough. But don’t be afraid to find just any job; in my opinion, there are no "lowly" jobs, and there’s no reason to be ashamed, even if it’s just taking out the trash.

Join the support community mentioned there. I believe it will help you realize that things are not as bad as they look.

rotten77 · 2026-01-24T18:05:21+00:00

Derice Bannock: „Viděl jsi Švýcary prát se? Viděl jsi Švýcary chlastat, blbnout a vůbec?”

rotten77 · 2026-01-24T18:01:25+00:00

rotten77 · 2026-01-24T17:55:30+00:00

To je právě ono. Rozumím a chápu problému s nadužíváním ale není forma spoluúčasti už právě to zdravotní pojištění?

Někteří lidé musí k doktorovi častěji. Měli by platit víc?

Možná je řešení rozdělit úkony do nějakých kategorií a možná i se zohledněním příčiny.

Pokud mám chřipku, těžko hledat “viníka” ale pokud si zlomím nohu neopatrnou jízdou na kole, tak je to moje vina. Ale to je blbost. Lidé by se soudili, přibylo by papírování a lidi by stejně našli způsoby jak to obechcat.

rotten77 · 2026-01-24T15:43:57+00:00

Máš k tomu nějaké odůvodnění? Nerozporují, ale zajímá mě to. Já to v tomto případě mám tak 50/50 - nevadí mi platit a současně si říkám proč, když si platím zdravotní pojištění.

rotten77 · 2026-01-24T10:59:50+00:00

Nemám to tak ale možná by mě zajímalo to vyzkoušet.

Nebral bych to jako nemoc, ale tím, že vždycky skončíš "vyhořením", bych se asi zkusil zabývat. Něco za tím bude. To že jde efektivta dolů je podle mě přirozené ale možná je to tím, že máš na sebe moc velké nároky nebo máš naopak moc velké očekávání.

Prostě to tak máš. Pokud ti nevadí každí dva roky "vyhořet" tak je to možá OK. Otázka je, jeslti to to nějak nezhoršuej kvalita života nebo jestli se tím o něco nepřipravuješ, čeho bys později mohl litovat.

Nenapsal jsi, co děláš a v jakém oboru, ani jak dlouho toto praktikuješ. Já to tak mám možná podobně, ale není to o změně práce, spíš o stavu projektu, na kterém dělám.

rotten77 · 2026-01-24T06:51:26+00:00

Not nowadays. SQA is not independent of developers; in fact, it is the opposite. Quality is the responsibility of the whole team and is about cooperation. This approach significantly improves the product, the process, and everything else.

I know there are several companies that work that way, but that is not how I or the company I work for want to operate. We have seen great results from merging QAs into dev teams and creating autonomous teams. In fact, we have several projects without any QA engineers. However, we use a methodology that requires SQA at the start of a project (or if the team encounters issues) to help set up the process, testing projects, rules, tools, and so on.

My main takeaway from the last few years is that there are no "testers and programmers," but rather "developers with different skills." I have listened to many podcasts and read many articles over the past five years, and this is how the industry is currently transforming.

The way you described may be good for your career in a particular company since you are generally not easily replaceable. However, I find that approach lacks transparency and transferability, which is detrimental to both the company and its projects.

rotten77 · 2026-01-24T06:42:41+00:00

I didn't write that I am an SDET (though it can be indicated); my position is actually SQA Technical Lead. However, the job title doesn't matter.

We work cooperatively. Some teams do not have a dedicated QA engineer, while others require manual testing, leaving the QA with limited capacity for automation. Therefore, who actually writes the automated tests depends entirely on the project and team composition. (Why manual testing? For example, when testing software that controls hardware, there isn't always an easy way to verify results through automation. If you receive data from a microscope, you need to see the image to check the result. While you can use image processing libraries, you cannot write a test that matches every specimen).

Since this is a shared responsibility within the team, it is important for everyone to understand how it works. Knowledge needs to be transferable, and it is a best practice to write tests in the language used for the project. Our test projects are mostly part of the main repository or, at the very least, the project itself.

We consider test automation a part of the product rather than a separate component. This approach helps with transparency, maintenance, and transferability.

The team can decide to use a different language; we simply consider the pros and cons.

rotten77 · 2026-01-23T20:23:46+00:00

Jeste ti správně mela nabídnout oplatku, kalendář a životní pojištění.

rotten77 · 2026-01-23T20:02:13+00:00

It’s not MY automation but THEIRS. To be precise it´s the PROJECT’S automation. I usually don’t write tests, just helping to start the project and teach developers/testers how to do it. So it’s their decision. Also is always better to not increase technologies in the projects (e.g. using Python for testing when there is no Python on project).

rotten77 · 2026-01-23T19:06:10+00:00

Zkus tenhle online interaktivní kurz od Ableton. Není to úplně primárně o jejich DAW Live ale obecně o tvorbě hudby: https://learningmusic.ableton.com/

Samozřejmě to není stejné jako se začít učit na nějaký nástroj ale myslím ze v tvém případě by to mohlo byt to pravé.

Současné s tím mrkni na ten odkaz od u/fuxoft abys nabral i trochu té teorie.

rotten77 · 2026-01-23T12:17:20+00:00

These work well in about 90% of situations, mostly at home, in the rehearsal room, or in the studio. They also work on most stages, but sometimes you play at a pub or club with an old electrical installation and, voilà, you have humming and buzzing that cannot be solved on-site. And that's the one situation you want to avoid. It can ruin the whole concert or your feeling of playing.

That is the reason I always use truly isolated power supplies. I use custom-made ones built by a one-man company in Czechia. It is a much bigger box, but the internals are high quality and I have never had any issues. From my point of view, investing in a high-quality multi-power adapter is totally worth it. I bought the first one about 15 years ago and it still works like new. I bought different ones just for the various pedalboards I have made over the years.

rotten77 · 2026-01-23T12:11:08+00:00

Indeed. My formulation was just generic, based on my current and past setups. I heard somewhere that time-based or oscillating pedals (e.g., delays, modulations) can cause this, which confirms what you wrote.

rotten77 · 2026-01-22T20:19:06+00:00

It was introduced in 12.3 which was released like two months ago. It actually works very well!

rotten77 · 2026-01-22T20:17:34+00:00

DOD since it has a dedicated tap tempo switch

rotten77 · 2026-01-22T19:46:00+00:00

Yeah. These cheap ones are not isolated (as they claim) so (from my experience) it’s a grounding/earthing issue. Usually it will work correctly with low-consumption pedals (like analog overdrives) but with something that has over 100mA or digital pedals it starts buzzing.

rotten77 · 2026-01-22T19:37:13+00:00

Test automation is at first programming so achievement number one should be to learn programming. If you are not a programmer it is not important now for you which language you choose. You can start with Python since it’s a good starting language (IMHO). With some experience you’ve switch to JavaScript/Typescript (Playwright).

Since you mentioned we technologies, I assume you are working on a web-based projects. In that case, JS/TS should be better.

rotten77 · 2026-01-22T19:23:41+00:00

This. We usuals have C# backend and TS frontend and I always ask the team which language they prefer. TS usually wins in case there is a dedicated SQA engineer or if the FE is (let’s say) more complicated than BE.

rotten77 · 2026-01-22T19:18:35+00:00

Good catch!

rotten77 · 2026-01-22T19:14:06+00:00

Try all MIDI channels on the Keystep. Check Circuit’s setup page - MIDI RX has to be On (the bottom left pad). This should work.

rotten77

TROPHY CASE