Hi guys, unfortunately i’m not very present here, but trying always to get updated with my old v1 kit.
But i encountered too much slow responsiveness and frequent xruns with any last Os versions (stable or testing)
Maybe the larger amount of new features is a bit too heavy for this older kit.
For example, loading just 3 channels with a Linuxsampler Piano, Helm and a Zynaddsubfx patch, can result in a medium-severe cpu load while playing just Helm (just to say) who is very cpu intensive, i understood
I don’t even pretend too much from my v1 kit, but would like even to load an older Os version, with less improvements but safe and more lightweight cpu management. @jofemodo do you remember a version of that kind i could download elsewhere in os.zynthian.org?
Actually didin’t find “legacy” folder anymore… so i didn’t try images by myself before asking here.
P.s.: V5 kit looks wonderful… maybe in future would have one
Hi @ivanmonterosso. It’s good to hear from you again. What Raspberry Pi model do you have in your Zynthian? Can you post a screenshot of the webconf dashboard?
Really happy of reading from you again! It’s good to know that there are some V1s alive by there.
It’s a long time i didn’t test with a V1. The latest ZynthianOS version should run “not much slower” than older versions, but the RBPi3 is quite CPU limited, and it would be worst if you have a RBPi2, that it’s not supported any more.
Could you check how is being consumed the CPU resources? You could use “top” from the command line to have a quick view.
Also please, send a screenshot from the webconf’s dashboard, so we can check the exact hardware you have.
Regarding legacy versions, i’ve some “gorgona” copy by here. Let me upload them to the download server and i will send you a link.
Hi, yes, i would someway try to submit something for competition, but must fight against laziness
Regarding zynthian kit, it’s the v1, so it’s a rbpi 3b, not overclocked. If i do, I’m afraid to roast cpu, there’s nothing more than its passive dissipation inside and it reaches 60º in few minutes just as is .
Anyway will post webconf asap
Oh thanks, yes of course a fresh Image, that’s for sure not an update … Will investigate soon with command. Just to say i should have some hardware issue too, because Select button sends unconditionally the power off signal every time i push it short ( not bold or long) and happens with any latest image i tried, and it’s quite strange. But this is another story . Curious to see if happens with this older one…
This image is a testing, as you can see from repositories, its april 26th snapshot.
but this condition i told happens even with stable ones (2021-9-25 too)
And this is the screenshot result of “top"command” with the mentioned test image, with idle unit (not playing anything, just sounds loaded).
@jofemodo damn, it’s really tiny,1.2gb! does it have sounds inside ?
actually just finished downloading now but archive extractor told me it’s damaged
Loaded sounds are these:
Playing all from external sequencer, the most intensive cpu process are zest and jalv.
But the weird fact is: while i’m testing and documenting this, zynthian is operating better as never done before with this OS
… the issue of poweroff command popping out after a short press of select button is still there
it’s generally not very stable, maybe tomorrow will turn on again dumb, very slow in movements thru pages and overloaded like past days… maybe should open that case and dive into a re-cablage … but i’m afraid to get it worse… this part scares me alot!
there still were dupont wires
I believe i should seriously work to enter the competition to win the V5
Top shows that jalv.gtk is running which suggests you have VNC enabled. This should be disabled as it takes significant extra resources to run the graphical environment and the GUIs for various engines.
mhmm…enabled but eve not using it, takes resources?.. ok got it,
but who knows why exactly now the bad guy it’s kidding me, playing pretty flawless with no xruns despite the significant cpu load
Clear, i understand any little stuff consuming resources, with this cpu power is relevant and makes the difference.
But… regarding this unwanted poweroff call: is there a way to inhibite this command just temporarily somewhere? and not by writing a longer delay for long press… already did it, and doesn’t work, and there are other long press functions would be affected.
Anyway thanks
You could tweak the code easily to prevent this, but it seems the select switch it’s broken and the release is not correctly detected. Tell me your address and i will send you a replacement for the encoder v1.
I think i’ve some spare parts by here.
Ooh nice thought … But before you send me something, i confess you a thing:
There’s more “secrets” inside that v1 enclosure than you can imagine
the original kit’s encoders actually didn’t work immediately, so i replaced some of them (don’t remember which one) with Arduino compatible encoders.
steps aren’t always precise but nothing annoying.
Then added additional buttons, more sensitive, to snapshot and select switches for avoiding stress to push encoder.
Everything Worked without issues until last 2 years.
Hope is nothing more than a short contact …
Anyway I’m trying to make some stuff for demo songs competition , in this conditions is a bit Difficult
.
?
… But before you send me something, i confess you a thing: