1.2-RC2 win32 on XP :Basic tests & test of sample-track

[musikBear]

I diddent feel that this should be an 'issue' on tracker, so i post my results for RC2 on XP here. Big thanks to @Zonkmachine for providing the binary 💯

ReleaseVersion: 1.2 RC2 win32 winXPsp3

*Basic function test

• installs
• opens
• preserve settings
• uses locale
• can change UI language
• load older project
• create project from template
• replay
• saves
• exports (new as loops too) correctly & with no problems on win32 xp

**VST-Instrument

• loads vst-instrument-container
• container loads dll
• access to lmms-controllers (wrench)
• LMMS controllers works
• automation works
• automation-connections preserved after save / load

**VST-Effects

• loads
• has effect (vst & ladspa)
• can be automated
• responds to general-FX (W/D)
• automation-connections preserved after save / load

**New sampleTrack

• load minute long sample (fast & reliable) from context from sidebar
• play
• delete sample
• reload
• delete track
• mute ** play
• unmute ** play

use as looper ( as https://www.youtube.com/watch?v=cCTaCs_8j2M drag-drop-copy context-copy context cut context paste move

• copy to new bars + play at var. pos
• clone ** repeat all above
• copy to other project in second lmms-instance (ctrl+drag ** repeat above on copied blocks
• 10 sample-tracks simultaneous ** different clips from different pos.

All of this was done simultaneous with a live tv channel! No crash, no cpu spikes or strange events. The live tv was not influenced at all!

Stunningly well done!

[zonkmachine]

I diddent feel that this should be an 'issue' on tracker

Correct. Can you also close this as its the tracker for the lmms web platform. Heaps of love for testing this though.

Stunningly well done!

:heart:

[tresf]

@musikBear I actually thought of you this release. This information would normally go into a QA/QC checklist. The matrices get very large very quickly and some of it can be automated but for starters can be a shared spreadsheet. If you are interested in spearheading this and sharing it out we can put basic pass/fail checks and make them a part of each release.

The various platforms would need to be addressed of course as well as basic upgrade tests, etc.

[musikBear]

| If you are interested in spearheading this and sharing it out we can put basic pass/fail checks and make them a part of each release. @tresf i can do that. Do you know a resource that is suited for a QAQC setup. I have openOffice, and can make a spreadsheet in that, but i am not sure where it can be posted as a shared resource

[tresf]

@musikBear you can start with open office, but Google Sheets is a good shared collaborative platform that I've used in the past, tracks changes and multiple people can be filling it out at the same time (If you're OK with Google of course). I believe it has ability to import from OOo (now known as Libre Office, BTW)

[musikBear]

@tresf

Google Sheets is a good shared collaborative platform :
(If you're OK with Google of course)

Thats fine, i have an old account. I suggest a structure where one 'version-in-os' has its own page. I feel that this structure makes sense, because the various versions are not directly related, and comparisons will still be possible in two different browser-windows. I will post a link when i have anything to show. Do you prefer this topic on HUB or just here?

[tresf]

Depends on the content. Sometimes one sheet with OS columns works. Try it out and see what works.

[tresf]

The topic is fine here for now. It's more of a "testers wanted" topic for tracker, FB and foruns, but best to have something in place first.

[musikBear]

I have been doing some in depth testing on RC2 https://docs.google.com/spreadsheets/d/1ecU1Zx4p8PVWucJElmgu-W5RM6lAcLnTk1y0sPgu4VA/edit#gid=1885868147 But then 23/1 i was prompted to change to RC8. This is fine, but i cant promise that the tests i did in RC2 also are valid for RC8. Normally when i did software tests, it was on a locked RC, and nothing was suppose to change in Master, during the tests of the RC. That procedure is of cause not an option in the lmms community, but i fear it is kind of futile to do this kind of testing, as long as the final RC isent locked, and ready to go. For that reason, i actually think that it is better to prospone this 'in-depth' test, until the 1.2.0 has been officially released, and then do this test on that release. I will for now continue 'usage-testing' and focus especially on all new features.

[tresf]

For that reason, i actually think that it is better to prospone this 'in-depth' test, until the 1.2.0 has been officially released, and then do this test on that release.

That's not how SDLC works. Bugs need to be identified BEFORE the stable release, not after.

I understand this creates repetitive tasks between RC releases. This is expected. Don't confuse testing the validity of a bug report with testing a product as a whole. The RC is what's being tested. There is no RC8, just a patch-8 to RC2, which isn't part of the formal QC process.