Current Server Time: 22:37 (Central Europe)

#apertus IRC Channel Logs

2020/04/29

Timezone: UTC


01:10
berto_bxl
left the channel
01:24
Bertl_oO
now after soldering a bunch of 0201 directly to the chip, I get the following serial console output
01:25
Bertl_oO
https://pastebin.com/raw/Gnqp64id
01:28
Bertl_oO
card boots without SD-mux and reads fine in the reader with SD-mux
01:29
comradekingu
left the channel
01:31
vup
well atleast we are getting to u-boot :)
01:31
Bertl_oO
doesn;'t happen reliably though
01:31
vup
hmm I see
01:31
Bertl_oO
i.e. sometimes it simply locks up, sometimes it gives the error
01:31
Bertl_oO
might be a matter of fine tuning the resistance though
01:33
Bertl_oO
still 11.5MB/s only too
01:45
comradekingu
joined the channel
01:52
Bertl_oO
got it booting!
01:53
Bertl_oO
ends with a kernel panic though
01:53
Bertl_oO
so probably still not perfect
01:54
Bertl_oO
tons of sdhci errors
03:11
Bertl_oO
hmm, that might be unrelated, i.e. some kind of data corruption on the card ...
03:32
mumptai_
joined the channel
03:35
mumptai
left the channel
03:37
vup
Yay re booting
03:37
vup
What was the problem / what made it boot?
03:38
Bertl_oO
well, I did put resistors where they are not supposed to be ...
03:39
vup
lol
03:39
Bertl_oO
i.e. on the MicroZed controller side
03:39
Bertl_oO
but it is not really a stable setup
03:40
Bertl_oO
bootloader works mostly, kernel starts but sdhci driver seems to fail in weird ways
03:40
vup
Well thats atleast something we have the source for / can change
03:41
Bertl_oO
yeah, I still think we need to fix the hardware in some weird way :)
03:42
vup
Yeah probably
03: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
03:50
vup
That sounds great
03:55
Bertl_oO
btw, soldering those resistors was fun! :)
03:56
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg
03:56
Bertl_oO
note: those are 0201 ;)
04:17
Bertl_oO
off to bed now ... have a good one everyone!
04:18
Bertl_oO
changed nick to: Bertl_zZ
04:24
metal_dent[m]
nn!
06:18
danieeel
changed nick to: danieel
06:19
BAndiT1983|away
changed nick to: BAndiT1983
06:20
BAndiT1983
metal_dent[m]: hi
06: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
06:25
metal_dent[m]
BAndiT1983: good morning!
06:26
metal_dent[m]
naming is okay afa we understand what that is :D
06:27
BAndiT1983
but should be straighten out at some point, as the calss is DebugPainter, but Painter has the method SetDebugOverlay()
06:27
metal_dent[m]
ImageButton is ready (referred PushButton), I'm thinking of testing it with WB screen first
06: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
06:29
BAndiT1983
why WB screen? my expectation would be that it works in every screen, e.g. settings screen
06:29
metal_dent[m]
just for testing i mean, it'll obviously work everywhere
06:30
BAndiT1983
i hope the code hasn't to be placed in every dialog
06: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
06:37
BAndiT1983
?
06:37
BAndiT1983
please read the doe of the ButtonBar again, it seems like you are missing a big point of this calss
06:37
BAndiT1983
*class
06:38
BAndiT1983
*code
06:40
BAndiT1983
"and draws the icons deriving from ImageButton" -> what do you mean?
06:44
metal_dent[m]
i understand the purpose of ButtonBar
06: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
06:46
BAndiT1983
please explain your last sentence, i don't understand it
06:49
BAndiT1983
you should look at this image: https://www.gamasutra.com/db_area/images/blog/mini2Dx/ClassHierarchy.png
06: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
06: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
06:51
metal_dent[m]
hmm hmm..
06:54
panintended
joined the channel
07:04
panintended
left the channel
07: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/
07: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/
07:20
BAndiT1983
using it on daily basis for my work and trying to incorporate it here, at least for the axiom remote project
07:21
metal_dent[m]
Yes, that's a better idea than explaining through words ':D
07:33
BAndiT1983
it's half past 8, i think se6ast1an will appear shortly ;)
07:45
se6ast1an
he did :)
07:50
BAndiT1983
hi
08:00
se6ast1an
good morning
08:00
se6ast1an
how are things going
08:03
BAndiT1983
excellent, as we are approaching the level of the previous firmware soon
08:03
se6ast1an
claimed the parameter menu task
08:03
BAndiT1983
that's good, will start with widget conversion later
08:06
metal_dent[m]
something like this -> https://www.plantuml.com/plantuml/svg/SoWkIImgAStDuUBAp2j9BKfBJ4vLy7GgBId9prFWIiv9B2vMWF2S4ekWVC_SnFHKL2N1cIcfG0KAN5mmlRgwTiWAkP0rWUIWEhZWXgE8SZcavgK0NGK0
08:06
metal_dent[m]
(just an idea, please suggest more..)
08:07
BAndiT1983
metal_dent[m]: sorry, but no, please explain why you derive a sidebar from a button?
08:09
BAndiT1983
start with basic explanations and i will suggest how to adjust the code and approach
08: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
08:10
metal_dent[m]
the ImageButton code only draws one icon and gives it color and background and highlighted colors when hovered
08:10
BAndiT1983
i think we should start with the tree hierarchy first, as your diagram is exactly inverted
08:10
metal_dent[m]
the SideBar class will make the "whole" bar with "all" the icons
08:10
BAndiT1983
normal approach is from big to small, let's do a quick discussion
08:11
metal_dent[m]
okay
08: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
08: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
08: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?
08:13
metal_dent[m]
yes yes!
08:13
BAndiT1983
At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on
08:13
BAndiT1983
baasic code is already there and working
08:14
BAndiT1983
which button types does the ButtonBar accept?
08:17
metal_dent[m]
currently only _bottomButtonBar is there in the IScreen, right?
08:17
BAndiT1983
yes
08:18
metal_dent[m]
okay so like that we need to make different bars for all the directions..
08:18
BAndiT1983
no
08:18
BAndiT1983
please check my question, as it is necessary to understand the basics of OOP, before advanced topics will kick in
08:19
metal_dent[m]
> At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on
08:19
metal_dent[m]
you just said that we need _topButtonBar, _bottonButtonBar.... ?
08: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
08:20
metal_dent[m]
yes the directions are wrongly placed ':D
08:21
se6ast1an
just pulled latest changes, great to see debug painter switch working in visualizer!
08:21
BAndiT1983
se6ast1an: can we add it to the Firmware and use some button for switching besides the 12 around the display?
08:22
BAndiT1983
metal_dent[m]: not directions, why should a bar derive from button?
08:23
se6ast1an
P13 would be a candidate I guess
08:23
metal_dent[m]
BAndiT1983: alright, I agree it's totally wrong... I had some idea.
08:23
BAndiT1983
a car class is not derived from a wheel class ;)
08:24
BAndiT1983
se6ast1an: great, maybe you can just grab the code from the visualiser, just 2 lines or so
08:24
se6ast1an
will check
08:24
se6ast1an
have a university video conference coming up soon
08:25
BAndiT1983
no problem, take your time, was just a nice to have option
08:26
BAndiT1983
metal_dent[m]: another nice topic in this direction -> https://en.wikipedia.org/wiki/Composition_over_inheritance
08:30
metal_dent[m]
yes
08:32
BAndiT1983
se6ast1an: my bad, build crashed because of version change, will push a fix quickly
08:33
se6ast1an
version change?
08:33
se6ast1an
builds fine here...
08:34
BAndiT1983
i mean CI build, updated to 2.40
08:34
BAndiT1983
https://app.circleci.com/pipelines/github/apertus-open-source-cinema/AXIOM-Remote
08:35
se6ast1an
ah
09:05
mumptai_
left the channel
09:06
mumptai
joined the channel
09:10
se6ast1an
P13 is not recognized currently, need to add that first
09:10
se6ast1an
which leads me to the issues I had with minicom and the ACM communication sending weird messages
09: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
09: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
09:15
BAndiT1983
metal_dent[m]: no problem, just ask questions, as many as you need to grasp things
09:15
se6ast1an
video conf now
09:15
RexOrCine
left the channel
09:18
BAndiT1983
se6ast1an: hope you have at least pants on
09:18
RexOrCine
joined the channel
09:19
se6ast1an
only the essentials :)
09:36
metal_dent[m]
BAndiT1983: I've one more ques (which I had asked you earlier but I'm still not sure):
09: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
09:39
BAndiT1983
of course, left, right, top and bottom, as we have a structure which is influenced by the hardware
09:45
metal_dent[m]
okay, thanks! I'll start by creating that :)
10:21
schmoggie1
joined the channel
10:22
schmoggie
left the channel
10:52
se6ast1an
video conf done
10:52
se6ast1an
BAndiT1983: how did you get pic32prog to run without requiring sudo?
11:04
se6ast1an
added the task so we dont forget
11:04
se6ast1an
https://lab.apertus.org/T1187
11:05
se6ast1an
my acm communication is currently weird so I cant get the i2c data required to add p13
11: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
11:17
BAndiT1983
the whole i2c communication is also not checked yet, will try to acquire the code for pic16 and look at it again
11:18
BAndiT1983
but we will probably move to UART in the future
11:24
se6ast1an
thanks, testing
11:24
se6ast1an
the i2c communication works great, why change that to uart?
11:26
se6ast1an
worked, great!
11:26
se6ast1an
will document in readme
11: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
11: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
11:36
se6ast1an
sounds not that essential atm
11: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
11:45
se6ast1an
remote is meant to be powered from the beta currently so power consumption optimization is not that important atm
11:47
BAndiT1983
remote is currently running in a constant loop, this is also a constant battery drain, which is not the target
11:47
BAndiT1983
our goal is to trigger the processing through interrupts
11:48
BAndiT1983
and without proper base, everything else won't work properly afterwards and would require a lot of adjustments
11:48
BAndiT1983
"it just works" won't work at some point also
12: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
12: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
12:15
se6ast1an
yes the bootloader sounds rather essential indeed
12: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
12: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
12:21
Bertl_zZ
changed nick to: Bertl
12:21
Bertl
morning folks!
12:22
Bertl
heard my name being typed in my dreams ... :)
12:22
BAndiT1983
must be a nightmare when i type it :P
12:22
BAndiT1983
'oh god, bandit has questions!!!'
12:23
Bertl
nah, not that bad
12:23
Bertl
btw, took a quick snap yesterday with the microscope: http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg
12:24
BAndiT1983
nice, thanks, quality is sufficient for most things it seems
12:25
Bertl
and you can get even better if you care to adjust the settings, which I didn't
12:26
Bertl
note that the parts are 0201, so 0.6x0.3mm (the black ones)
12:31
BAndiT1983
is any lag involved or can you solder beneath it without a bigger problem?
12:35
Bertl
in general I suggest not to solder with an USB microscope for several reasons
12:35
Bertl
first, there is an inevitable lag, but it is quite short especially at higher framerates
12:35
BAndiT1983
second the smoke
12:36
Bertl
second, you do not have any 3D information
12:36
BAndiT1983
but there are microscopes with a filter in front of the lens
12:36
Bertl
so you do not know how far away from the PCB you are
12:36
BAndiT1983
true
12:36
BAndiT1983
what do you use for such small soldering? magnifying glass or goggles?
12:36
Bertl
and finally you need something to remove the smoke before it reaches the microscope
12:37
Bertl
which is a problem if the distance to the object is really short
12:37
Bertl
I use an opticial stereo microscope with a long working distance
12:40
Bertl
something like the Bresser Biorit or the AmScope SE400 are perfect
12:41
Bertl
you typically want 5-15x magnification for soldering and at least 10cm 'room' below the optics
12:44
berto_bxl
joined the channel
12:46
BAndiT1983
thanks, will check it
12:49
BAndiT1983
Bertl: regarding I2C and U(S)ART topic, how did we came to the discussion back then?
12:53
berto_bxl
hello
12:54
se6ast1an
hi bertrand!
12: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 ?
12: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
12:58
se6ast1an
berto_bxl: what exactly is the problem?
13: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?
13:01
berto_bxl
Hdmi signal doesn't seem to acces "media express"
13:03
se6ast1an
I just checked, the hyperdeck shuttle only support 1080p25/30
13: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)
13:04
se6ast1an
the beta is outputting 50/60p
13: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
13:05
BAndiT1983
Bertl: ok, good to know, but you don't have any preference regarding which to use there?
13:05
se6ast1an
at the office we use a black magic decklink 4k mini recorder which works fine with the beta hdmi signal
13:06
Bertl
BAndiT1983: no real preference here, but UART is definitely a good choice for the task
13:06
BAndiT1983
Bertl: because...
13:08
Bertl
most communications in both directions will be 'fire' and 'forget'
13:08
Bertl
like for example 'key down', 'key up', 'set led'
13:09
Bertl
so having a one way information exchange vs. an I2C transaction looks more natural
13:10
berto_bxl
se6ast1an: thx
13:10
Bertl
BAndiT1983: it should also be reasonably reliable on the PCB
13:10
BAndiT1983
sounds like the problem with asynchronous and synchronous responses at my job, asynchronous are easier to handle
13: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
13:12
BAndiT1983
*struggle
13:13
BAndiT1983
which is less the case for a microcontroller
13:13
Bertl
the main reason I went for I2C is the fact that a lot can happen on the button manager side
13:14
Bertl
let's say the user is turning the knob and pressing a button
13:14
Bertl
the knob will send quite a number of 'events' as it changes
13: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
13:15
BAndiT1983
as long as the position is not totally off
13:15
Bertl
of course, this can be also done via UART pin-pong
13:16
Bertl
or just by rate limiting the UART events from the keymanager side
13:16
BAndiT1983
this was what i also was thinking about if we should reduce the flood of events
13:17
Bertl
so as I said, no real preference here, I2C was simply chosen because I used the same on the Axiom Mainboard PICs
13:17
BAndiT1983
reaction/response time for the user was already defined in researches, have to check what looks fluent to the user
13:19
BAndiT1983
https://www.nngroup.com/articles/response-times-3-important-limits/
13: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
13:21
Bertl
25 FPS IMHO should be the minimum for direct visual feedback
13:21
Bertl
30 FPS would be better and in any case, they should be synced to the LCD rate
13: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
13:22
Bertl
so e.g. with 60 Hz refresh, 20 or 30 FPS
13:22
BAndiT1983
our LCD has its buffer, so we don't have to worry about keeping the data all the time
13:22
BAndiT1983
*-keeping +supplying
13:23
Bertl
yes, updates are only relevant if there is some change on the display
13: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
13:24
BAndiT1983
right, because of the scanline
13:24
BAndiT1983
we have enough timers to utilize one as LCD sync/update timer
13:32
BAndiT1983
command 0x45h should also give us the current scanline, but i don't remember the refresh rate we use currently
13:36
Bertl
probably the simplest is to phase lock the timer interrupt
13: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?
13:39
Bertl
well, let's look how you do it practically :)
13:40
Bertl
a simple approach is to 'guess' the correct timer setting to hit the blanking every time
13:40
BAndiT1983
i would just do while(0x45 != 0)
13:40
BAndiT1983
pseudocode of course
13:40
Bertl
if you make sure that your guess is on the short side, i.e. shorter delay than actually necessary
13:41
Bertl
you simply wait for the actual blanking to arrive
13:41
Bertl
in the next step, you can dynamically adjust the timer interval to match the actual framerate
13: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
13:42
BAndiT1983
have to test it, shouldn't be that difficult i guess
13: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'
13:55
Bertl
(but that will probably add quite some overhead)
13:57
BAndiT1983
as the display controller has nice features already, we can try with scanline check
13:58
BAndiT1983
luckily it's in the base set of commands
14:09
BAndiT1983
Bertl: which mode is to prefer in our case, data enable or sync?
14:10
BAndiT1983
looked at the ili9341 docs, but am not sure which is suitable
14:11
Bertl
hmm?
14: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
14:18
BAndiT1983
aaand this is level 2 command, bad luck
14:21
Bertl
there is the TE pin which I used for the lcd.hex example
14:21
berto_bxl
left the channel
14:21
Bertl
you can put that on an interrupt and set/adjust a timer from there
14:32
mumptai
left the channel
14:33
mumptai
joined the channel
16:39
panintended
joined the channel
16:58
se6ast1an
hi panintended
16:58
se6ast1an
are you still suffering from this bug: https://lab.apertus.org/T1181 ?
16:58
se6ast1an
or did you find a way to avoid it?
17: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
17: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
17:09
panintended
left the channel
17:53
BAndiT1983
pickit3 reset to MPLAB mode, board flashed but not excited about performance, something is dragging it down
17:56
BAndiT1983
additionally the knob is working in reverse, clockwise goes up and not down in the menu
17:57
BAndiT1983
although the values are positive in clockwise direction and negative in counter-clockwise
17:58
BAndiT1983
changed nick to: BAndiT1983|away
18:06
metal_dent[m]
BAndiT1983: I added _leftButtonBar in the IScreen and also modified the ImageButton class a bit
18:35
Spirit532
left the channel
18:36
Spirit532
joined the channel
18:41
se6ast1an
interesting BAndiT1983|away, maybe different rotary encoders have been soldered to me/your board
18:41
Bertl
unlikely
18:43
Bertl
but by now, the PIC16 code might differ
19:09
se6ast1an
right
19:32
panintended
joined the channel
19:33
panintended
hi all, I was out today. Reading up on the log now
19:42
BAndiT1983|away
changed nick to: BAndiT1983
19: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
19:52
BAndiT1983
panintended: hi, have you seen my comment about the possible fix?
20:19
panintended
BAndiT1983: yes
20:20
BAndiT1983
se6ast1an: are you currently extending the settings menu?
20: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
21:17
panintended
BAndiT1983: yes, sure. I'll claim the task too
21:18
BAndiT1983
thanks
21:18
panintended
no problem
21:19
BAndiT1983
if you need more details, just give a ping
21:38
mumptai
left the channel
21:42
BAndiT1983
finally found the link for led linearization, which was used for currently used array, and commented the LCD dimming task
21:42
BAndiT1983
off for today, good night
21:42
BAndiT1983
changed nick to: BAndiT1983|away
21:47
se6ast1an
great
21:47
se6ast1an
I will work on the parameter menu tomorrow, have no additions for settings menu planned currently other than parameter menu
22:11
se6ast1an
off to bed, good night
22:20
panintended
left the channel
23:03
panintended
joined the channel
23:47
panintended
left the channel
23:47
panintended
joined the channel
00: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.
00:02
panintended
left the channel