QB64 Phoenix Edition v3.8.0 Released!
#1
QB64 Phoenix Edition v3.8.0!

https://github.com/QB64-Phoenix-Edition/...tag/v3.8.0

Enhancements
  • #338 - C/C++ compiler update. - @a740g
    • Updates the MinGW toolchain to v12.2.0 r2.
  • #339 - Improvements on the various dialog functions. - @a740g
    • Many mandatory dialog parameters are now optional.
    • Parsable option string arguments are case-insensitive now (required lower case before).
  • #341 - Adds _UCHARPOS() to the _U* functions family. - @a740g
    • Ideally, this should have been added in v3.7.0 but was not due to an oversight. This function calculates the pixel distance of every character in a string from the origin and is especially helpful for variable width fonts.
  • #347 - Audio enhancements. - @a740g
    • Updates miniaudio to v0.11.17, which adds support for Apple AIFF and AIFC audio formats. So, we get those too.
    • PLAY has been extended to:
      • Select waveforms @n (square = 1, sawtooth = 2, triangle = 3 (default), sine = 4, noise = 5).
      • Adjust volume ramping Qn (0ms to 100ms).
    • SOUND has been extended to use the following syntax:
      • SOUND frequency#, duration#[, volume#][, panning#][, waveform&]
  • #346 - Improves the IDE code export abilities. - @RhoSigma-QB64
    • Added ability to export into a [ q b = e x p o r t ] Forum codebox.
    • The Forum/Wiki exports now go to the clipboard instead of a file and can directly be pasted into the Forum post or Wiki page.
    • Progress of export is shown in the status line and you'll get a message upon export completion.

Bug Fixes
Full Changelog: v3.7.0...v3.8.0
Reply
#2
Heart 
Yay! Go team! The new Unicode graphics printing stuff keeps getting better and better.

I imagine a muzak contest, the winner because he/she kept changing the waveform of PLAY statement during playback!

The additional functionality to SOUND is great, but it's destined to do only one-channel sound. One still has to work for multichannel playback with _SNDRAW and the like. ON PLAY() was never supported by QB64. This is just a reminder for the ambitious ones.
Reply
#3
(06-14-2023, 12:36 PM)mnrvovrfc Wrote: The additional functionality to SOUND is great, but it's destined to do only one-channel sound. One still has to work for multichannel playback with _SNDRAW and the like. ON PLAY() was never supported by QB64. This is just a reminder for the ambitious ones.
Muli-channel SOUND is a planned feature. This update just lays the foundation for that to happen. If things go as planned, we might even implement custom waveforms.

See this issue report:  Amiga BASIC like
WAVE
and
SOUND
improvements · Issue #187 · QB64-Phoenix-Edition/QB64pe (github.com)


The ON PLAY() stuff would surely be a nice-to-have feature. But that is not on our roadmap yet. Please feel free to add it to the QB64-PE GitHub issue tracker.
Reply
#4
As usual: Excellent work! And all for the fun of it! - Hey, at MS would they you with the greatest pleasure.

My dream is  Rolleyes : VisualBasic 6...(without the Net crap) with QB64. Then Basic would be at the top again, because there are many problems in business practice where Basic is better - simpler, but the result is right. That's the most important!

And now I'm going to watch a good old movie  Tongue : Forbidden Planet
Reply
#5
@Kernelpanic
there are two vb6-compatible compilers in the works but they are subscription based, twinBasic and RAD basic
because I only make tiny programs for pastime I never tried them, I heard that twinBasic has a free 32-bit version
Reply
#6
(06-14-2023, 08:19 PM)Kernelpanic Wrote: And now I'm going to watch a good old movie  Tongue : Forbidden Planet
Follow up with "Day the earth stood still." Idea
Reply
#7
(06-14-2023, 08:19 PM)Kernelpanic Wrote: My dream is  Rolleyes : VisualBasic 6...(without the Net crap) with QB64. Then Basic would be at the top again, because there are many problems in business practice where Basic is better - simpler, but the result is right. That's the most important!

People would still program in assembly language, COBOL, FORTRAN, LISP, Perl and Python because there is a lot of pride about it and because there are millions of U.S.A. dollars consumed by code that has been maintained for decades. There is much less such code for BASIC than for those other languages. BASIC would have had to be in LISP's place in existence and would have had to become pervasive after 10 years to have a chance of a BASIC utopia.
Reply
#8
(06-14-2023, 10:56 PM)Jack Wrote: @Kernelpanic
there are two vb6-compatible compilers in the works but they are subscription based, twinBasic and RAD basic

Subscriptions Rolleyes

A lame way to remain in business, forcing everybody to get Internet. Double it up -- with iLok and other wicked things to keep people at the yoke and to keep a constant stream of alarmists that "I will lose it all if I can't pay for it". It's no use telling the alarmist: if the software is already installed on your computer although it's not the latest version, but you could still use it, even if you have to plug in the dongle or whatever, and you don't have to go online ever, then what's the problem? Yes there are actually people like this in the forums concentrating on music technology. I used to belong to one.

For monthly payment I expect something continuously improved, but how long could they last like this? Until they suddenly close down but still demand the user's money? Nope.
Reply
#9
Could someone explain how the new version ties in with [ qb = export ]  ?

Will we be able to run QB64pe v 3.8 code in a code window like we can with [ qbjs ] ?
b = b + ...
Reply
#10
(06-15-2023, 03:24 PM)bplus Wrote: Will we be able to run QB64pe v 3.8 code in a code window like we can with [ qbjs ] ?

It will require in the least a plug-in that fuses between the web browser and the QB64 IDE.

Remember that QBJS is an independent effort by dbox and others which has nothing to do with "traditional" QB64 for Windows, MacOS or Linux. The trick with QBJS works because it could be run entirely without leaving the web browser or using another program, or even worse, an inefficient plug-in.

Maybe a program could be written that could capture the text in a code block on this forum, then it invokes the QB64 IDE, loads the text in as program and then runs it automatically. But it would be slow since the "traditional" QB64 has a lot of overhead. It's tantalizing what could be done with QBJS and then one wants to be able to do the same thing with the QB64 that existed long before QBJS.
Reply




Users browsing this thread: 9 Guest(s)