Propeller Tool will always lag behind PNut (until the final release). If you do install Propeller Tool, I suggest doing it outside of the (x86) folder as Windows treats that differently and makes manual access of the /Libraries sub-folder a hassle. I'm a bit nutty about formatting so I'm sticking with Propeller Tool for editing and coding, but hoping that @"Jeff Martin" will be able to get the new compiler engine into it shortly so I can experiment with some of the new debugging features.
Nice work - The new PNut Ver.34y works great and no sign of any nasty code virus.
Stepping back and reviewing: - What is the preferred installation of Ver.34y ? - Either in the Windows/../Program Files(86)/Parallax - or - any sub-directory you want? I am currently using the Documents directory and everything seems fine.
Secondly - Running PNut Ver.34y directly gives no screen color formatting, just a text screen. I use add-in 2.2.0.0 Alpha for full editing capability. Everything appears to work nicely.
Given all of that - How do I know that 2.2.0.0 Alpha is picking up and running PNut Ver.34y ??? Is there any printable version function I can use to be absolutely sure?
I just put the PNut.exe file wherever my code files are, also.
By 2.2.0.0 Alpha, do you mean PropellerTool? I don't think that has had a new PNut compiler installed in a while, but Jeff is working on that this week.
It would be nice if PNut could point to a library folder. One of the reason I hesitate to use PNut is that it creates a lot of files that are not cleaned up, and I don't want these polluting my /Library folder.
It would be nice if PNut could point to a library folder. One of the reason I hesitate to use PNut is that it creates a lot of files that are not cleaned up, and I don't want these polluting my /Library folder.
Ah, good point. I could make it delete those files. I agree. It makes a mess.
It would be nice if PNut could point to a library folder. One of the reason I hesitate to use PNut is that it creates a lot of files that are not cleaned up, and I don't want these polluting my /Library folder.
Ah, good point. I could make it delete those files. I agree. It makes a mess.
Maybe this needs to be a switchable option.
I currently have to use Pnut to generate .obj files which I then include in Propeller Tool source because it doesn't generate .obj files.
Flipping between the two tools requires clear focus.
Possible bug in 34y. Could someone please validate the following:
File | Open... "DEBUG_plot"
Modify file. I placed an "a" at end of file. I've also tried commenting out code.
Run | Compile + Load RAM + Debug
When asked to confirm changes by saving file, choose "No" button.
PNut goes nonresponsive.
Possible bug in 34y. Could someone please validate the following:
File | Open... "DEBUG_plot"
Modify file. I placed an "a" at end of file. I've also tried commenting out code.
Run | Compile + Load RAM + Debug
When asked to confirm changes by saving file, choose "No" button.
PNut goes nonresponsive.
Is it just me?
I will try this out in the morning. This must be some latent bug.
I wouldn't classify the following as a "bug", maybe a "feature". I'm smiling! That's what my NASA programmers would call a noncritical bug.
I have a Microsoft Surface Pro 7 as my primary display and a HDMI monitor over USB C as my secondary display.
The debug windows open in the same display PNut is in.
In the primary display, PNut's display configuration options perform as expected.
In the secondary display, the 'myplot' window opens in the upper left corner of the screen (as expected), however, it's title bar displays 485, -1080 not "myplot - Plot".
The TITLE option does not work unless the POS 485 -1080 [or higher] option was used. I figured out the default position 0 0 was the problem. Anything lower than 485,-1080 was treated like a relative location. For instance, POS 10 10, placed the window at 495, -1070, however the TITLE option would not work.
PS>>I forgot to mention. I commented out the main body of code. I'm only testing the first debug() call, otherwise the options work was expected. The second debug() call somehow fixes the feature.
Possible bug in 34y. Could someone please validate the following:
File | Open... "DEBUG_plot"
Modify file. I placed an "a" at end of file. I've also tried commenting out code.
Run | Compile + Load RAM + Debug
When asked to confirm changes by saving file, choose "No" button.
PNut goes nonresponsive.
Is it just me?
Yes, I see there's a problem. If the user doesn't want to save his file, the compilation shouldn't proceed. I'm looking into this now.
Here's the SPECTROgraph. I was speaking into it "1, 2, 3,..20". It was using the LUMA8X mode which goes from black, through a color, to white, in $00..$FF:
Here's the SPECTROgraph. I was speaking into it "1, 2, 3,..20". It was using the LUMA8X mode which goes from black, through a color, to white, in $00..$FF:
Wow! Chip it looks cool. I think that Newton would have loved it LOL
I added 16-bit HSV display modes for BITMAP and SPECTRO(graph) modes. Here is a picture of all their pixel values:
Are these HSV colour modes amenable to output via the P2 itself, or at least simple to map? It may be good to try to keep the graphics capabilities within what the P2 could itself generate (with HyperRAM if required) in case this information will be presented by a P2 one day.
I added 16-bit HSV display modes for BITMAP and SPECTRO(graph) modes. Here is a picture of all their pixel values:
Are these HSV colour modes amenable to output via the P2 itself, or at least simple to map? It may be good to try to keep the graphics capabilities within what the P2 could itself generate (with HyperRAM if required) in case this information will be presented by a P2 one day.
I could have put these HSV color modes into the silicon if I had thought about them at the time, but it didn't occur to me back then. Too bad. To compute them in the PC, I make a color table of 256 saturated hues, then I blend them with black, white, or both, depending on the mode. It's probably a bit much to do at display-time on the P2. I needed such a mode to represent phase and power for the spectrograph display. I also added those bitmap modes that end in 'W', which saturate from white, and the 'X' modes which span from black to white, with the color in-between. So, the graphical debug has several more modes than the P2, but covers all the P2 modes.
Here is the RGB-to-HSV pattern:
In the HSV modes, bits[15..8] of the pixel select the color and bits[7..0] select the saturation, from black, from white, or from black to white.
We could possibly use a 16bit to 32bit table to quickly remap this HSV to RGB24 pixels but it burns 256kB (or perhaps 192kB if somehow compressed) to map the colours. Although if there are multiple variants shown simultaneously this table approach probably grows out of control. Maybe a 16bit HSV to 16bit RGB map might be better to save memory. So as you receive the data, you do a lookup and remap to 16bit RGB colour. We could also use the RGBEXP instruction to then expand to 24 bits.
Today I made a MIDI debug display. It recognizes 'note on' and 'note off' events and shows them on an 88-key keyboard:
Wow!! this is great , I love MIDI stuff
I wanted to have a MIDI display that I could use for the chorus synthesizer that I still need to write for Wednesday. I thought it would be neat to use the keyboard in real-time to synthesize the chorus from a microphone input.
I wanted to have a MIDI display that I could use for the chorus synthesizer that I still need to write for Wednesday. I thought it would be neat to use the keyboard in real-time to synthesize the chorus from a microphone input.
A chorus synthesizer and I think you said on Wed that you were going to add pitch bend too? . Sounds really great . I can't wait for the demo on Wed.
@ cgracey
oday I made a MIDI debug display. It recognizes 'note on' and 'note off' events and shows them on an 88-key keyboard:
I made a MIDI output display program about 10 years ago in Delphi . I used to use it for troubleshooting the IVL Steel Rider pitch to MIDI device designed for Pedal Steel Guitar. When I plucked a string it would show what MIDI note the Steel Rider was sending out. the Pedal Steel Guitar uses a chromatic tuning (String 1 = F#4, String 2 = D#4, String 3 G#4, String 4 = E4, String 5 = B3, String 6 = G#3, String 7= F#3, String 8 = E3, Sting 9= D3, String 10 = B2) It was nothing fancy but it sure was handy, when testing.
That's pretty neat, Bob. Does it always give note-off events right after the pluck? And what do the related velocity values indicate?
I tried some shading to indicate velocity, but it didn't look good. Maybe I need to start the color at the bottom of each key and then make its height proportional to the velocity. It would be nice to make the color fade to black or white at some height, but that would probably take too much CPU time.
It was fun getting the keyboard graphics worked out. It took just a little code after some realizations. I draw the 52 white keys first, then the 36 black keys on top, since they overlap the white keys. This way, I can use just Canvas.RoundRect to draw the keys with a slight edge radius and outline. It's quite simple and looks almost photographic.
That's pretty neat, Bob. Does it always give note-off events right after the pluck? And what do the related velocity values indicate?
Thanks! Chip, It was fun at the time because I just got started with MIDI and diden't know much about MIDI then.
I did this program so long ago and haven't used it since 2007(I thought that I did this around 10 years ago but it was around 16(2014) years ago. LOL) that I hardly remember how it works. I found a Pascal MIDI class somewere on the web, at the time and just added the parts that I needed.
Yes, each time you pluck the string. If I remember correctly, velocity is the Midi info for volume, indicating how hard I plucked the string.
Bob, I'm a MIDI fan also. If I can get all my gear together in one place, (900 miles away), I'll set up a shop with my keyboards.
Still moving for the last time!!
Tonight I got around to making multiple DEBUG displays feedable from single commands. This improves efficiency quite a bit when you want to send the same data to multiple windows:
I was going to add some polar-coordinate commands to the PLOT window, but I realized I could just make a keyword "POLAR" to put the plot window into polar mode, so that what are in the (x,y) positions become (rho,theta). Things like 'left bottom right top' become 'rho theta width height'. When a box or oval is drawn, then the (x,y) coordinates are left in the middle, so that text can be placed inside without any extra coordinates. The default justification for text printing is horizontal and vertical centering to make most things simple.
I will add a command for drawing rounded rectangles and I think it will be kind of complete for now.
I was wishing there was a way around needing a full 32-bit angle for the polar coordinates in PLOT, so I added a few optional operands to POLAR. The first value defines how many angle units are in a circle (negative values are clockwise) and the second is an offset to be applied to each angle. This lets you set up any arbitrary division you want and place the zero-angle where you want it. Here is how you can achieve a clock face. See 'POLAR -12 -3':
I've been thinking that objects could include a section of special DEBUG commands, maybe given another name, which could be compiled and run exclusively, in order to provide animated documentation for the object. A picture explains a lot more than text, but a moving picture gets lots of concepts across really fast.
Comments
I just put the PNut.exe file wherever my code files are, also.
By 2.2.0.0 Alpha, do you mean PropellerTool? I don't think that has had a new PNut compiler installed in a while, but Jeff is working on that this week.
Ah, good point. I could make it delete those files. I agree. It makes a mess.
I currently have to use Pnut to generate .obj files which I then include in Propeller Tool source because it doesn't generate .obj files.
Flipping between the two tools requires clear focus.
File | Open... "DEBUG_plot"
Modify file. I placed an "a" at end of file. I've also tried commenting out code.
Run | Compile + Load RAM + Debug
When asked to confirm changes by saving file, choose "No" button.
PNut goes nonresponsive.
Is it just me?
I will try this out in the morning. This must be some latent bug.
I have a Microsoft Surface Pro 7 as my primary display and a HDMI monitor over USB C as my secondary display.
The debug windows open in the same display PNut is in.
In the primary display, PNut's display configuration options perform as expected.
In the secondary display, the 'myplot' window opens in the upper left corner of the screen (as expected), however, it's title bar displays 485, -1080 not "myplot - Plot".
The TITLE option does not work unless the POS 485 -1080 [or higher] option was used. I figured out the default position 0 0 was the problem. Anything lower than 485,-1080 was treated like a relative location. For instance, POS 10 10, placed the window at 495, -1070, however the TITLE option would not work.
PS>>I forgot to mention. I commented out the main body of code. I'm only testing the first debug() call, otherwise the options work was expected. The second debug() call somehow fixes the feature.
Yes, I see there's a problem. If the user doesn't want to save his file, the compilation shouldn't proceed. I'm looking into this now.
I added 16-bit HSV display modes for BITMAP and SPECTRO(graph) modes. Here is a picture of all their pixel values:
Wow! Chip it looks cool. I think that Newton would have loved it LOL
Seeing is believing...
Are these HSV colour modes amenable to output via the P2 itself, or at least simple to map? It may be good to try to keep the graphics capabilities within what the P2 could itself generate (with HyperRAM if required) in case this information will be presented by a P2 one day.
I could have put these HSV color modes into the silicon if I had thought about them at the time, but it didn't occur to me back then. Too bad. To compute them in the PC, I make a color table of 256 saturated hues, then I blend them with black, white, or both, depending on the mode. It's probably a bit much to do at display-time on the P2. I needed such a mode to represent phase and power for the spectrograph display. I also added those bitmap modes that end in 'W', which saturate from white, and the 'X' modes which span from black to white, with the color in-between. So, the graphical debug has several more modes than the P2, but covers all the P2 modes.
Here is the RGB-to-HSV pattern:
In the HSV modes, bits[15..8] of the pixel select the color and bits[7..0] select the saturation, from black, from white, or from black to white.
Here is a video of it working:
Here is the complete program that runs on the P2:
CON _clkfreq = 250_000_000 rxpin = 23 DAT org asmclk debug ("`midi m pos 100 1000 size 4") wrpin #%11111_0,#rxpin wxpin ##(clkfreq_ / 31_250) << 16 + 8-1, #rxpin drvl #rxpin .wait testp #rxpin wc if_nc jmp #.wait rdpin x,#rxpin shr x,#32-8 debug ("`m ", uhex_byte_(x)) jmp #.wait x res 1Wow!! this is great , I love MIDI stuff
I wanted to have a MIDI display that I could use for the chorus synthesizer that I still need to write for Wednesday. I thought it would be neat to use the keyboard in real-time to synthesize the chorus from a microphone input.
A chorus synthesizer and I think you said on Wed that you were going to add pitch bend too? . Sounds really great . I can't wait for the demo on Wed.
@ cgracey
I made a MIDI output display program about 10 years ago in Delphi . I used to use it for troubleshooting the IVL Steel Rider pitch to MIDI device designed for Pedal Steel Guitar. When I plucked a string it would show what MIDI note the Steel Rider was sending out. the Pedal Steel Guitar uses a chromatic tuning (String 1 = F#4, String 2 = D#4, String 3 G#4, String 4 = E4, String 5 = B3, String 6 = G#3, String 7= F#3, String 8 = E3, Sting 9= D3, String 10 = B2) It was nothing fancy but it sure was handy, when testing.
I tried some shading to indicate velocity, but it didn't look good. Maybe I need to start the color at the bottom of each key and then make its height proportional to the velocity. It would be nice to make the color fade to black or white at some height, but that would probably take too much CPU time.
It was fun getting the keyboard graphics worked out. It took just a little code after some realizations. I draw the 52 white keys first, then the 36 black keys on top, since they overlap the white keys. This way, I can use just Canvas.RoundRect to draw the keys with a slight edge radius and outline. It's quite simple and looks almost photographic.
Thanks! Chip, It was fun at the time because I just got started with MIDI and diden't know much about MIDI then.
I did this program so long ago and haven't used it since 2007(I thought that I did this around 10 years ago but it was around 16(2014) years ago. LOL) that I hardly remember how it works.
Yes, each time you pluck the string. If I remember correctly, velocity is the Midi info for volume, indicating how hard I plucked the string.
It's amazing on how perfect it looks
Still moving for the last time!!
I will add a command for drawing rounded rectangles and I think it will be kind of complete for now.
Interesting.
Mike