Current Server Time: 10:48 (Central Europe)

#apertus IRC Channel Logs

2020/04/29

Timezone: UTC


00:10
berto_bxl
left the channel
00:24
Bertl_oO
now after soldering a bunch of 0201 directly to the chip, I get the following serial console output
00:25
Bertl_oO
https://pastebin.com/raw/Gnqp64id
00:28
Bertl_oO
card boots without SD-mux and reads fine in the reader with SD-mux
00:29
comradekingu
left the channel
00:31
vup
well atleast we are getting to u-boot :)
00:31
Bertl_oO
doesn;'t happen reliably though
00:31
vup
hmm I see
00:31
Bertl_oO
i.e. sometimes it simply locks up, sometimes it gives the error
00:31
Bertl_oO
might be a matter of fine tuning the resistance though
00:33
Bertl_oO
still 11.5MB/s only too
00:45
comradekingu
joined the channel
00:52
Bertl_oO
got it booting!
00:53
Bertl_oO
ends with a kernel panic though
00:53
Bertl_oO
so probably still not perfect
00:54
Bertl_oO
tons of sdhci errors
02:11
Bertl_oO
hmm, that might be unrelated, i.e. some kind of data corruption on the card ...
02:32
mumptai_
joined the channel
02:35
mumptai
left the channel
02:37
vup
Yay re booting
02:37
vup
What was the problem / what made it boot?
02:38
Bertl_oO
well, I did put resistors where they are not supposed to be ...
02:39
vup
lol
02:39
Bertl_oO
i.e. on the MicroZed controller side
02:39
Bertl_oO
but it is not really a stable setup
02:40
Bertl_oO
bootloader works mostly, kernel starts but sdhci driver seems to fail in weird ways
02:40
vup
Well thats atleast something we have the source for / can change
02:41
Bertl_oO
yeah, I still think we need to fix the hardware in some weird way :)
02:42
vup
Yeah probably
02:42
Bertl_oO
have a bunch of ideas to track this down though ... just need to get some parts and do some additional modifications and tests
02:50
vup
That sounds great
02:55
Bertl_oO
btw, soldering those resistors was fun! :)
02:56
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg
02:56
Bertl_oO
note: those are 0201 ;)
03:17
Bertl_oO
off to bed now ... have a good one everyone!
03:18
Bertl_oO
changed nick to: Bertl_zZ
03:24
metal_dent[m]
nn!
05:18
danieeel
changed nick to: danieel
05:19
BAndiT1983|away
changed nick to: BAndiT1983
05:20
BAndiT1983
metal_dent[m]: hi
05:20
BAndiT1983
committed adjusted debug painter yesterday, debug overlay button should work now, just not happy about my naming of some classes and methods at the moment, but this is the least of the problems
05:25
metal_dent[m]
BAndiT1983: good morning!
05:26
metal_dent[m]
naming is okay afa we understand what that is :D
05:27
BAndiT1983
but should be straighten out at some point, as the calss is DebugPainter, but Painter has the method SetDebugOverlay()
05:27
metal_dent[m]
ImageButton is ready (referred PushButton), I'm thinking of testing it with WB screen first
05:28
BAndiT1983
have updated the docker script to version 2.40 of XC32, hope it still works, as this release by microchip took half a year this time, usually they do it a bit more often
05:29
BAndiT1983
why WB screen? my expectation would be that it works in every screen, e.g. settings screen
05:29
metal_dent[m]
just for testing i mean, it'll obviously work everywhere
05:30
BAndiT1983
i hope the code hasn't to be placed in every dialog
05:32
metal_dent[m]
yes, so to do that we need another class which makes a sidebar (like button bar) and draws the icons deriving from ImageButton
05:37
BAndiT1983
?
05:37
BAndiT1983
please read the doe of the ButtonBar again, it seems like you are missing a big point of this calss
05:37
BAndiT1983
*class
05:38
BAndiT1983
*code
05:40
BAndiT1983
"and draws the icons deriving from ImageButton" -> what do you mean?
05:44
metal_dent[m]
i understand the purpose of ButtonBar
05:45
metal_dent[m]
i meant that we'll define a class which derives from ImageButton, there we'll make the sidebar with the help of ButtonBar
05:46
BAndiT1983
please explain your last sentence, i don't understand it
05:49
BAndiT1983
you should look at this image: https://www.gamasutra.com/db_area/images/blog/mini2Dx/ClassHierarchy.png
05:49
BAndiT1983
the goal of the UI is to have a tree-like structure, where the elements are leaves and are updated iteratively, depending on their state or happened action
05:51
BAndiT1983
https://www.researchgate.net/profile/Maria_Gemou/publication/221908814/figure/fig2/AS:305243830145029@1449787208370/LWUIT-Widget-library-class-hierarchy-Moreover-the-Lightweight-UI-Toolkit-library.png
05:51
metal_dent[m]
hmm hmm..
05:54
panintended
joined the channel
06:04
panintended
left the channel
06:12
BAndiT1983
metal_dent[m]: please make a drawing of your planned structure, so i can check it and give you proper advices, you can use either gdoc or draw.io -> https://app.diagrams.net/
06:20
BAndiT1983
what i would also suggest is, to learn plantuml, there is also a plugin for vscode or one can use online editors, like https://www.planttext.com/
06:20
BAndiT1983
using it on daily basis for my work and trying to incorporate it here, at least for the axiom remote project
06:21
metal_dent[m]
Yes, that's a better idea than explaining through words ':D
06:33
BAndiT1983
it's half past 8, i think se6ast1an will appear shortly ;)
06:45
se6ast1an
he did :)
06:50
BAndiT1983
hi
07:00
se6ast1an
good morning
07:00
se6ast1an
how are things going
07:03
BAndiT1983
excellent, as we are approaching the level of the previous firmware soon
07:03
se6ast1an
claimed the parameter menu task
07:03
BAndiT1983
that's good, will start with widget conversion later
07:06
metal_dent[m]
something like this -> https://www.plantuml.com/plantuml/svg/SoWkIImgAStDuUBAp2j9BKfBJ4vLy7GgBId9prFWIiv9B2vMWF2S4ekWVC_SnFHKL2N1cIcfG0KAN5mmlRgwTiWAkP0rWUIWEhZWXgE8SZcavgK0NGK0
07:06
metal_dent[m]
(just an idea, please suggest more..)
07:07
BAndiT1983
metal_dent[m]: sorry, but no, please explain why you derive a sidebar from a button?
07:09
BAndiT1983
start with basic explanations and i will suggest how to adjust the code and approach
07:09
metal_dent[m]
to actually draw the bar which will have the icons and the button handlers and if we want to implement the bar in a screen (like WB) then we'll just add that class in that dialog
07:10
metal_dent[m]
the ImageButton code only draws one icon and gives it color and background and highlighted colors when hovered
07:10
BAndiT1983
i think we should start with the tree hierarchy first, as your diagram is exactly inverted
07:10
metal_dent[m]
the SideBar class will make the "whole" bar with "all" the icons
07:10
BAndiT1983
normal approach is from big to small, let's do a quick discussion
07:11
metal_dent[m]
okay
07:11
BAndiT1983
the base of the task is a sidebar, which should have 3 UI buttons, as we have 4 sides with 3 buttons on each side of the display
07:12
BAndiT1983
this is almost the root of the whole thing, as we need to tie it to something, it should be placed in the base class of the screens, namely IScreen
07:12
BAndiT1983
IScreen is still not the abstract interface it should be and we would introduce Screen which derives from it later, remember our discussion yesterday?
07:13
metal_dent[m]
yes yes!
07:13
BAndiT1983
At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on
07:13
BAndiT1983
baasic code is already there and working
07:14
BAndiT1983
which button types does the ButtonBar accept?
07:17
metal_dent[m]
currently only _bottomButtonBar is there in the IScreen, right?
07:17
BAndiT1983
yes
07:18
metal_dent[m]
okay so like that we need to make different bars for all the directions..
07:18
BAndiT1983
no
07:18
BAndiT1983
please check my question, as it is necessary to understand the basics of OOP, before advanced topics will kick in
07:19
metal_dent[m]
> At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on
07:19
metal_dent[m]
you just said that we need _topButtonBar, _bottonButtonBar.... ?
07:19
BAndiT1983
yes, but this is not important at the moment, as the structure is there, but i try to explain OOP side of it, as your diagram shows totally different picture of what should be done
07:20
metal_dent[m]
yes the directions are wrongly placed ':D
07:21
se6ast1an
just pulled latest changes, great to see debug painter switch working in visualizer!
07:21
BAndiT1983
se6ast1an: can we add it to the Firmware and use some button for switching besides the 12 around the display?
07:22
BAndiT1983
metal_dent[m]: not directions, why should a bar derive from button?
07:23
se6ast1an
P13 would be a candidate I guess
07:23
metal_dent[m]
BAndiT1983: alright, I agree it's totally wrong... I had some idea.
07:23
BAndiT1983
a car class is not derived from a wheel class ;)
07:24
BAndiT1983
se6ast1an: great, maybe you can just grab the code from the visualiser, just 2 lines or so
07:24
se6ast1an
will check
07:24
se6ast1an
have a university video conference coming up soon
07:25
BAndiT1983
no problem, take your time, was just a nice to have option
07:26
BAndiT1983
metal_dent[m]: another nice topic in this direction -> https://en.wikipedia.org/wiki/Composition_over_inheritance
07:30
metal_dent[m]
yes
07:32
BAndiT1983
se6ast1an: my bad, build crashed because of version change, will push a fix quickly
07:33
se6ast1an
version change?
07:33
se6ast1an
builds fine here...
07:34
BAndiT1983
i mean CI build, updated to 2.40
07:34
BAndiT1983
https://app.circleci.com/pipelines/github/apertus-open-source-cinema/AXIOM-Remote
07:35
se6ast1an
ah
08:05
mumptai_
left the channel
08:06
mumptai
joined the channel
08:10
se6ast1an
P13 is not recognized currently, need to add that first
08:10
se6ast1an
which leads me to the issues I had with minicom and the ACM communication sending weird messages
08:14
metal_dent[m]
BAndiT1983: i looked at the code more closely and i think i got the present structure regarding the ButtonBar, IScreen, IButton, etc. and agree that we don't need another SideBar class which i was proposing, sorry for the wrong structure ':D
08:14
BAndiT1983
which ones? is the button 13 connected properly to the PIC16? last question is supposedly yes, but i still haven't looked up the connection schema, as the button handling wasn't adjusted yet
08:15
BAndiT1983
metal_dent[m]: no problem, just ask questions, as many as you need to grasp things
08:15
se6ast1an
video conf now
08:15
RexOrCine
left the channel
08:18
BAndiT1983
se6ast1an: hope you have at least pants on
08:18
RexOrCine
joined the channel
08:19
se6ast1an
only the essentials :)
08:36
metal_dent[m]
BAndiT1983: I've one more ques (which I had asked you earlier but I'm still not sure):
08:36
metal_dent[m]
won't we need a _leftButtonBar like this -> https://github.com/MetalDent/AXIOM-Remote/blob/dev/Firmware/UI/Screens/IScreen.cpp#L5
08:39
BAndiT1983
of course, left, right, top and bottom, as we have a structure which is influenced by the hardware
08:45
metal_dent[m]
okay, thanks! I'll start by creating that :)
09:21
schmoggie1
joined the channel
09:22
schmoggie
left the channel
09:52
se6ast1an
video conf done
09:52
se6ast1an
BAndiT1983: how did you get pic32prog to run without requiring sudo?
10:04
se6ast1an
added the task so we dont forget
10:04
se6ast1an
https://lab.apertus.org/T1187
10:05
se6ast1an
my acm communication is currently weird so I cant get the i2c data required to add p13
10:14
BAndiT1983
se6ast1an: you have to check with lsusb the PID/VID first, then create a rule, like here -> https://github.com/sergev/pic32prog/wiki/Using-PICkit3, see troubleshooting section
10:17
BAndiT1983
the whole i2c communication is also not checked yet, will try to acquire the code for pic16 and look at it again
10:18
BAndiT1983
but we will probably move to UART in the future
10:24
se6ast1an
thanks, testing
10:24
se6ast1an
the i2c communication works great, why change that to uart?
10:26
se6ast1an
worked, great!
10:26
se6ast1an
will document in readme
10:30
BAndiT1983
one example is power consumption, as we don't need to poll every time, but get a pin change trigger from outside, which should reactivate pic32 from sleep and so on
10:30
BAndiT1983
this would also simplify the button handling, as at the moment one has to do the binary operations to check if the button was triggered at all, which results in unnecessary operations
10:36
se6ast1an
sounds not that essential atm
10:41
BAndiT1983
but it is rather essential and was discussed with Bertl several months ago, as we need proper hardware handling also, at the moment most development is about UI, which is hiding the essentials like proper bootloader and using remote with battery, which requires quite some adjustments to the processing
10:45
se6ast1an
remote is meant to be powered from the beta currently so power consumption optimization is not that important atm
10:47
BAndiT1983
remote is currently running in a constant loop, this is also a constant battery drain, which is not the target
10:47
BAndiT1983
our goal is to trigger the processing through interrupts
10:48
BAndiT1983
and without proper base, everything else won't work properly afterwards and would require a lot of adjustments
10:48
BAndiT1983
"it just works" won't work at some point also
11:10
se6ast1an
I am fully on board for creating a "proper base" - what I mean is that the focus should be on getting a useable device into the hands of early adopter users asap meaning we focus on the essentials first and deal with the nice-to-have later on
11:14
BAndiT1983
then somebody should continue with bootloader, as at the moment we have only some tinkering base and not solid fundament with possibilities to restore the remote if firmware fails, don't think that people want to acquire pickit2/3 just to flash firmware
11:15
se6ast1an
yes the bootloader sounds rather essential indeed
11:19
BAndiT1983
we have a lot of things we have to push and hardware-related side cannot be omitted, but i have to check the latest state first, will revert my pickit to MPLAB mode again, so i can at least flash with IPE, as pic32prog wasn't successful, tried also different branch, still no luck
11:20
BAndiT1983
this is where we need the help from Bertl and his remote remote, so maybe Priya or someone else can write code and test remotely
11:21
Bertl_zZ
changed nick to: Bertl
11:21
Bertl
morning folks!
11:22
Bertl
heard my name being typed in my dreams ... :)
11:22
BAndiT1983
must be a nightmare when i type it :P
11:22
BAndiT1983
'oh god, bandit has questions!!!'
11:23
Bertl
nah, not that bad
11:23
Bertl
btw, took a quick snap yesterday with the microscope: http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg
11:24
BAndiT1983
nice, thanks, quality is sufficient for most things it seems
11:25
Bertl
and you can get even better if you care to adjust the settings, which I didn't
11:26
Bertl
note that the parts are 0201, so 0.6x0.3mm (the black ones)
11:31
BAndiT1983
is any lag involved or can you solder beneath it without a bigger problem?
11:35
Bertl
in general I suggest not to solder with an USB microscope for several reasons
11:35
Bertl
first, there is an inevitable lag, but it is quite short especially at higher framerates
11:35
BAndiT1983
second the smoke
11:36
Bertl
second, you do not have any 3D information
11:36
BAndiT1983
but there are microscopes with a filter in front of the lens
11:36
Bertl
so you do not know how far away from the PCB you are
11:36
BAndiT1983
true
11:36
BAndiT1983
what do you use for such small soldering? magnifying glass or goggles?
11:36
Bertl
and finally you need something to remove the smoke before it reaches the microscope
11:37
Bertl
which is a problem if the distance to the object is really short
11:37
Bertl
I use an opticial stereo microscope with a long working distance
11:40
Bertl
something like the Bresser Biorit or the AmScope SE400 are perfect
11:41
Bertl
you typically want 5-15x magnification for soldering and at least 10cm 'room' below the optics
11:44
berto_bxl
joined the channel
11:46
BAndiT1983
thanks, will check it
11:49
BAndiT1983
Bertl: regarding I2C and U(S)ART topic, how did we came to the discussion back then?
11:53
berto_bxl
hello
11:54
se6ast1an
hi bertrand!
11:55
berto_bxl
just wondering, on the wiki it is said that recording has been tested with intensity shuttle blackmagick. doesn't seem to work on my side. Any idea ?
11:56
Bertl
BAndiT1983: IIRC, you complained about the polling for button presses and wanted something event driven and I suggested to switch to serial (UART) instead
11:58
se6ast1an
berto_bxl: what exactly is the problem?
12:01
BAndiT1983
Bertl: this is also what i remember, as polling was colliding with the idea of bootloader a bit, do you have some suggestions about implementing it or postponing?
12:01
berto_bxl
Hdmi signal doesn't seem to acces "media express"
12:03
se6ast1an
I just checked, the hyperdeck shuttle only support 1080p25/30
12:03
Bertl
BAndiT1983: should be fairly simple to do, tests can be done on one side on the existing hardware (where the PIC32 pins are UART capable)
12:04
se6ast1an
the beta is outputting 50/60p
12:04
Bertl
BAndiT1983: on the new remote prototoypes the pin assignment was changed so both sides can use I2C or UART which should ensure a seamless transition
12:05
BAndiT1983
Bertl: ok, good to know, but you don't have any preference regarding which to use there?
12:05
se6ast1an
at the office we use a black magic decklink 4k mini recorder which works fine with the beta hdmi signal
12:06
Bertl
BAndiT1983: no real preference here, but UART is definitely a good choice for the task
12:06
BAndiT1983
Bertl: because...
12:08
Bertl
most communications in both directions will be 'fire' and 'forget'
12:08
Bertl
like for example 'key down', 'key up', 'set led'
12:09
Bertl
so having a one way information exchange vs. an I2C transaction looks more natural
12:10
berto_bxl
se6ast1an: thx
12:10
Bertl
BAndiT1983: it should also be reasonably reliable on the PCB
12:10
BAndiT1983
sounds like the problem with asynchronous and synchronous responses at my job, asynchronous are easier to handle
12:11
BAndiT1983
in this case UART is asynchronous and i2c synchronous, so latter one give us trouble when response does not arrive on time, then the struggles begins
12:12
BAndiT1983
*struggle
12:13
BAndiT1983
which is less the case for a microcontroller
12:13
Bertl
the main reason I went for I2C is the fact that a lot can happen on the button manager side
12:14
Bertl
let's say the user is turning the knob and pressing a button
12:14
Bertl
the knob will send quite a number of 'events' as it changes
12:15
Bertl
but the PIC32 most likely only cares about the position when the button was pressed or a 'periodical' snapshot or even just the 'final' position
12:15
BAndiT1983
as long as the position is not totally off
12:15
Bertl
of course, this can be also done via UART pin-pong
12:16
Bertl
or just by rate limiting the UART events from the keymanager side
12:16
BAndiT1983
this was what i also was thinking about if we should reduce the flood of events
12:17
Bertl
so as I said, no real preference here, I2C was simply chosen because I used the same on the Axiom Mainboard PICs
12:17
BAndiT1983
reaction/response time for the user was already defined in researches, have to check what looks fluent to the user
12:19
BAndiT1983
https://www.nngroup.com/articles/response-times-3-important-limits/
12:20
BAndiT1983
0.1 seconds is a bit low, but we don't update the screen constantly, at least it won't be the case soon, as currently a loop does it
12:21
Bertl
25 FPS IMHO should be the minimum for direct visual feedback
12:21
Bertl
30 FPS would be better and in any case, they should be synced to the LCD rate
12:21
BAndiT1983
yes, if we do animations on the remote, but most screens are rather static, so we would update only when something happens, either external trigger or button, which is also one
12:22
Bertl
so e.g. with 60 Hz refresh, 20 or 30 FPS
12:22
BAndiT1983
our LCD has its buffer, so we don't have to worry about keeping the data all the time
12:22
BAndiT1983
*-keeping +supplying
12:23
Bertl
yes, updates are only relevant if there is some change on the display
12:23
Bertl
what I mean is, if you turn the knob and a list scrolls along as you turn it or some value increases/decreases the rate of change should be constant and in sync
12:24
BAndiT1983
right, because of the scanline
12:24
BAndiT1983
we have enough timers to utilize one as LCD sync/update timer
12:32
BAndiT1983
command 0x45h should also give us the current scanline, but i don't remember the refresh rate we use currently
12:36
Bertl
probably the simplest is to phase lock the timer interrupt
12:38
BAndiT1983
this is where i'm a bit clueless, i know it's about syncing 2 devices, but how do you do it theoretically?
12:39
Bertl
well, let's look how you do it practically :)
12:40
Bertl
a simple approach is to 'guess' the correct timer setting to hit the blanking every time
12:40
BAndiT1983
i would just do while(0x45 != 0)
12:40
BAndiT1983
pseudocode of course
12:40
Bertl
if you make sure that your guess is on the short side, i.e. shorter delay than actually necessary
12:41
Bertl
you simply wait for the actual blanking to arrive
12:41
Bertl
in the next step, you can dynamically adjust the timer interval to match the actual framerate
12:42
Bertl
another approach would be to read the scanline, guess the time you need to wait for a blanking interval, then set the timer
12:42
BAndiT1983
have to test it, shouldn't be that difficult i guess
12:55
Bertl
btw, a third approach would be to have a high frequency interrypt check for scanline/blanking and trigger the update whenever 'the time is right'
12:55
Bertl
(but that will probably add quite some overhead)
12:57
BAndiT1983
as the display controller has nice features already, we can try with scanline check
12:58
BAndiT1983
luckily it's in the base set of commands
13:09
BAndiT1983
Bertl: which mode is to prefer in our case, data enable or sync?
13:10
BAndiT1983
looked at the ili9341 docs, but am not sure which is suitable
13:11
Bertl
hmm?
13:12
BAndiT1983
nevermind, will read more into it later, but i see that we have no setup for the frequency, at least it's not that clear in the code
13:18
BAndiT1983
aaand this is level 2 command, bad luck
13:21
Bertl
there is the TE pin which I used for the lcd.hex example
13:21
berto_bxl
left the channel
13:21
Bertl
you can put that on an interrupt and set/adjust a timer from there
13:32
mumptai
left the channel
13:33
mumptai
joined the channel
15:39
panintended
joined the channel
15:58
se6ast1an
hi panintended
15:58
se6ast1an
are you still suffering from this bug: https://lab.apertus.org/T1181 ?
15:58
se6ast1an
or did you find a way to avoid it?
16:04
BAndiT1983
we can add automatic fallback, like panintended suggested, creating the context for imgui should try with core profile, otherwise use the one which works at the moment
16:06
BAndiT1983
on my hardware it works with both without a problem, only ubuntu VM shows black like yours, so maybe panintended can add a fix by extending the initialization
16:09
panintended
left the channel
16:53
BAndiT1983
pickit3 reset to MPLAB mode, board flashed but not excited about performance, something is dragging it down
16:56
BAndiT1983
additionally the knob is working in reverse, clockwise goes up and not down in the menu
16:57
BAndiT1983
although the values are positive in clockwise direction and negative in counter-clockwise
16:58
BAndiT1983
changed nick to: BAndiT1983|away
17:06
metal_dent[m]
BAndiT1983: I added _leftButtonBar in the IScreen and also modified the ImageButton class a bit
17:35
Spirit532
left the channel
17:36
Spirit532
joined the channel
17:41
se6ast1an
interesting BAndiT1983|away, maybe different rotary encoders have been soldered to me/your board
17:41
Bertl
unlikely
17:43
Bertl
but by now, the PIC16 code might differ
18:09
se6ast1an
right
18:32
panintended
joined the channel
18:33
panintended
hi all, I was out today. Reading up on the log now
18:42
BAndiT1983|away
changed nick to: BAndiT1983
18:52
panintended
se6ast1an: yes, the issue (T1181) is still there for me. for the time being, I have changed the relevant lines in Main.cpp in my local repo
18:52
BAndiT1983
panintended: hi, have you seen my comment about the possible fix?
19:19
panintended
BAndiT1983: yes
19:20
BAndiT1983
se6ast1an: are you currently extending the settings menu?
19:32
BAndiT1983
panintended: could you add the fix? at the moment i have to check what is required on the firmware side and help metal_dent[m] to understand the structure, but have to shift my focus also more to the bootloader, as it was dormant for quite some time and contains important hardware setup, like memory layout and other "fun" stuff
20:17
panintended
BAndiT1983: yes, sure. I'll claim the task too
20:18
BAndiT1983
thanks
20:18
panintended
no problem
20:19
BAndiT1983
if you need more details, just give a ping
20:38
mumptai
left the channel
20:42
BAndiT1983
finally found the link for led linearization, which was used for currently used array, and commented the LCD dimming task
20:42
BAndiT1983
off for today, good night
20:42
BAndiT1983
changed nick to: BAndiT1983|away
20:47
se6ast1an
great
20:47
se6ast1an
I will work on the parameter menu tomorrow, have no additions for settings menu planned currently other than parameter menu
21:11
se6ast1an
off to bed, good night
21:20
panintended
left the channel
22:03
panintended
joined the channel
22:47
panintended
left the channel
22:47
panintended
joined the channel
23:02
panintended
Hi all. I think I've pinpointed what's causing https://lab.apertus.org/T1181 and added a comment. Have a look and let me know if the proposed change works for you.
23:02
panintended
left the channel