Activity for MicOscope
-
Ivo Šmerek posted a comment on ticket #1
I fully respect that. Sometimes I'm so hardly focused only on the Linux world that I often forget that there are other platforms as well. But I would still suggest you to make a "fully qt5 enabled version" as a default, since qt5 is nowadays standard and keep qt4 support for backporting. You can release portable .exe file for Windows users, right? And if they really want to build it from source, they should be able to install qt5.
-
UTillyty modified a comment on ticket #1
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily built statically for either linux, windows and osx, whilst for qt5 is a nightmare (this is important expecially to make your software gracefully...
-
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily built statically for either linux, windows and osx, whilst for qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, windows and osx, while qt5 is a nightmare (this is important expecially for windows, as qt has never been widespread...
-
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and osx, while qt5 is a nightmare (this is important expecially for windows, as qt has never been widespread...
-
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and macintosh, while qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
Well, in fact there are no good reasons to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and macintosh, while qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
Well, in fact there are no good reason to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and macintosh, while qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
Well, in fact there are no good reason to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to now because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and macintosh, while qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
Well, in fact there are no good reason to "stick" to anything, but that should not force you to abandon a platform just because there is a newer version, what is important is to keep compatibility in mind. As far as I'm concerned I've kept using qt4 up to know because: - it definitely works; - it's lighter and can run in very old pc's: - it can be easily build statically for either linux, window and macintosh, while qt5 is a nightmare (this is important expecially for windows, as qt has never been...
-
That makes sense. I'm wondering, is there a reason to stick with qt4 when it is no longer supported for a few years, qt5 is a nowadays standard in all Linux distributions and qt6 is slowly making its way to the scene? https://www.qt.io/blog/qt-6.0-released
-
I noticed one thing. In version I compiled, there is one major difference In qt4 it wasn't possible to set the input volume as in qt5, so I put that "image of audio inputs" as an aesthetic filler, in place of the working volume knob that shows up if you build with qt5. For a binary portable package (statically linked with all the dependencies including qt), qt4 was preferable, but I had already put some conditional compilation switch for future releases with qt5. So, I guess that time has come (at...
-
Do you plan to release those changes in 1.2? I'm asking because I would like to create a Gentoo ebuild for this package to build from the source It is soon said: I will shortly publish this last changes as 1.1 (I haven't yet released) and after some housecleaning and a thorough test I will release 1.2. Keep in touch!
-
I noticed one thing. In version I compiled, there is one major difference. Instead of image of audio inputs: there is some sort of trimmer preset: Is it bug or feature? :) Edit. Now I noticed it actually works and has a title. My bad...
-
I noticed one thing. In version I compiled, there is one major difference. Instead of image of audio inputs: there is some sort of trimmer preset: Is it bug or feature? :)
-
I noticed one thing. In version I compiled, there is one major difference. Instead of image of audio inputs: there is some sort of trimmer preset: Is it bug or feature? :)
-
Works like a charm. Thank you! Do you plan to release those changes in 1.2? I'm asking because I would like to create a Gentoo ebuild for this package to build from the source. I currently have ebuild for sci-electronics/micoscope-1.1.ebuild but it's a binary. . (I preferred link the static library locally compiled to be more 'portable' not having to install external packages) . Yes, but as you can see now, for me as a user (even as a package manager) it is much easier to run just one command (or...
-
The first problem is quickly resolved (I preferred link the static library locally compiled to be more 'portable' not having to install external packages): locate the linux specific section in the MicOscope.pro file: linux-g++ | linux-g++-64 | linux-g++-32 { and replace the current INCLUDEPATH and LIBS (below I just commented out both with a leading '#') with aLIBS line as follows (the INCLUDEPATHis not needed any more): #INCLUDEPATH += $$PWD/../fftw-3.3.8/api #LIBS += -L$$PWD/../fftw-3.3.8/.libs...
-
The first problem is quickly resolved (I linked the static library locally compiled to be more 'portable' not having to install external packages): locate the linux specific section in the MicOscope.pro file: linux-g++ | linux-g++-64 | linux-g++-32 { and replace the current INCLUDEPATH and LIBS (below I just commented out both with a leading '#') with aLIBS line as follows (the INCLUDEPATHis not needed any more): #INCLUDEPATH += $$PWD/../fftw-3.3.8/api #LIBS += -L$$PWD/../fftw-3.3.8/.libs -l:libfftw3.a...
-
use standard ~/config path if linux qt5 (dynamic linked)
-
Hello, thank you for the fast response! Your changes did the trick and I managed to successfully compile the source. But there are few things I found. Would it be possible to use system fftw libraries and do not hardcore them even with specific 3.3.8 version to the code? g++ ..... -L/home/ivo/Download/micoscope-src-r180/../fftw-3.3.8/.libs -l:libfftw3.a /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -l:libfftw3.a I use Gentoo linux and have package sci-libs/fftw...
-
Hi and thank you very much for your interest! I verified what you noticed and resolved the error adding a line of code in the file common.h. After that I encountered another error (I was not recompiling for a while) due to an update in the Qt5 library, and resolved as well, with some minor bug fix. You can see what I've changed here -> https://sourceforge.net/p/micoscope/src/180/ Since from the the last time I've published the source (version 1.0, commit r175) I've resolved a couple of bugs, but...
-
Compilation error
-
Thank you very much for your interest! I verified what you noticed and resolved the error adding a line of code in the file common.h. After that I encountered another error (I was not recompiling for a while) due to an update in the Qt5 library, and resolved as well, with some minor bug fix. You can see what I've changed here -> https://sourceforge.net/p/micoscope/src/180/ Since from the the last time I've published the source (version 1.0, commit r175) I've resolved a couple of bugs, but I've not...
-
Thank you very much for your interest! I verified what you noticed and resolved the error adding a line of code in the file common.h. After that I encountered another error (I was not recompiling for a while) due to an update in the Qt5 library, and resolved as well, with some minor bug fix. You can see what I've changed here -> https://sourceforge.net/p/micoscope/src/180/ Since from the the last time I've published the source (version 1.0, commit r175) I've resolved a couple of bugs, but I've not...
-
Compilation error
-
Thank you very much for your interest! I verified what you noticed and resolved the error adding a line of code in the file common.h. After that I encountered another error (I was not recompiling for a while) due to an update in the Qt5 library, and resolved as well, with some minor bug fix. You can see what I've changed here -> https://sourceforge.net/p/micoscope/src/180/ Since from the the last time I've published the source (version 1.0, commit r175) I've resolved a couple bugs, but I've not yet...
-
fixed ticket #1 (Q_DECLARE_METATYPE); replaced toAscii -> toLatin1
-
Compilation error
-
MicOscope released /micoscope-linux/micoscope-linux-x86_64-1.1.tar.gz
-
test commit on pc-2
-
linux x86_64 build #1
-
fftw-3.3.7->3.3.8
-
UTillyty committed [r176]
bug fix: wav-play buff size
-
-
-
-
-
version 1.0
-
gen bug on ch2
-
UART tooltips
-
-
sampling shift bug fix
-
-
lib
-
osx
-
tooltips: functionpanel
-
-
tolltips: CTR
-
NO 24 bit
-
win32 build (FFTW-3.2.2)
-
tooltips
-
save data
-
GaugeF
-
about
-
-
uart debug
-
uart tx out
-
UART TX pcm + loopback; edge_seek bug fix
-
UART codec
-
UART rec
-
uart parity/stop
-
-
UART dialog
-
uart parse
-
pcmcpy
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1 >