Page 4 of 14
Re: Flowstone Guru Blog
Posted: Sun Oct 05, 2014 10:17 am
by KG_is_back
Exo wrote:So the debugging article I am writing is turning out to be long one and my bad attention span is affecting my ability to finish it.
So I have written a quick article on allowing us to
Expand the DSP component , this would be a great feature . If you are interested in such a thing add your 2 cents in the comments. I am thinking of directing Malc to this article and asking him to give it some serious consideration.
ah a good article. I'm waiting for such improvement since I learned assembly in SM. The way I imagine it is to perhaps have a separate component "DSP code functions" which would be a modified assembler. Also an expansion of stream integers would be very helpful. Like having a streamInt connector in FS that would receive green integers looselessly (for bitwise masks and stuff...). and off course expanding the opcodes so we may have ability to subtract integers (the only way to do that currently is to use andnps in a way that it works as a not gate - to make integer negative... but the andnps has a longstanding coloring bug)
By the way I may add some suggestions on debugging too if you're interrested - just PM me the article if you need any help with it
Re: Flowstone Guru Blog
Posted: Sun Oct 05, 2014 6:10 pm
by Exo
KG_is_back wrote:Exo wrote:So the debugging article I am writing is turning out to be long one and my bad attention span is affecting my ability to finish it.
So I have written a quick article on allowing us to
Expand the DSP component , this would be a great feature . If you are interested in such a thing add your 2 cents in the comments. I am thinking of directing Malc to this article and asking him to give it some serious consideration.
ah a good article. I'm waiting for such improvement since I learned assembly in SM. The way I imagine it is to perhaps have a separate component "DSP code functions" which would be a modified assembler. Also an expansion of stream integers would be very helpful. Like having a streamInt connector in FS that would receive green integers looselessly (for bitwise masks and stuff...). and off course expanding the opcodes so we may have ability to subtract integers (the only way to do that currently is to use andnps in a way that it works as a not gate - to make integer negative... but the andnps has a longstanding coloring bug)
By the way I may add some suggestions on debugging too if you're interrested - just PM me the article if you need any help with it
Yes I think a component like "DSP code Functions" would be a good Idea. The problem I have with DSP code and ASM well with all things stream really is that they seem to have been developed to a point where they are "Good enough" for everyday use, ie writing basic algorithms, but then it got left at that so now we are in a situation where one of Flowstones strongest points is becoming one of it's weakest areas and needs a major revamp as far as I am concerned.
By the way I added you as an editor to Flowstone guru, now you can login and take a look (and edit) the article, it is under "Posts" in the dashboard menu. any help would be appreciated. So far I have just started off by going into the importance of a tidy schematic , saving often and testing often. I need to get into the specifics of debugging now and inspecting values ect..
Make changes if you like or just give me a few suggestions (via PM) if you do make changes there is a "save draft" button in top right corner, this saves the draft as a separate revision so won't over write anything I have done, thanks.
Re: Flowstone Guru Blog
Posted: Tue Oct 07, 2014 5:30 pm
by Exo
OK so I finished the debugging article!
Debugging in FlowstoneIt could have been so much longer! and I am not 100 percent happy with it but guess I can still edit and improve it in future.
Re: Flowstone Guru Blog
Posted: Tue Oct 07, 2014 6:44 pm
by KG_is_back
Exo wrote:OK so I finished the debugging article!
Debugging in FlowstoneIt could have been so much longer! and I am not 100 percent happy with it but guess I can still edit and improve it in future.
Actually it might not be bad to make debuging articles for specific sections of flowstone (ruby, green, view, stream and assembler) and go more in depth. Possibly making a list of most common bugs within the specific section. The best format for that would probably be PDF in the download sections, cos' things may get added in the future.
This would naturally be a big collaborative project... definitely something for Guru to make

I have several assembly tricks and tips to share as that is probably the most painful thing to debug.
Re: Flowstone Guru Blog
Posted: Tue Oct 07, 2014 6:56 pm
by Exo
KG_is_back wrote:Exo wrote:OK so I finished the debugging article!
Debugging in FlowstoneIt could have been so much longer! and I am not 100 percent happy with it but guess I can still edit and improve it in future.
Actually it might not be bad to make debuging articles for specific sections of flowstone (ruby, green, view, stream and assembler) and go more in depth. Possibly making a list of most common bugs within the specific section. The best format for that would probably be PDF in the download sections, cos' things may get added in the future.
This would naturally be a big collaborative project... definitely something for Guru to make

I have several assembly tricks and tips to share as that is probably the most painful thing to debug.
Yes you are right this article should be just an overview I think , I wanted to get across some best practices and thought processes. Each section of Flowstone could easily have an article of it's own as long if not longer than that one!
So really this article isn't doing each area justice I became very aware of just how inadequate the article was when I started considering all the different areas of Flowstone.
But yes an article or PDF for each section of Flowstone would be best, then if more Gurus get involved we could each focus on our main area of expertise. For instance I couldn't possibly do debugging in Ruby justice but Trogluddite has done some amazing work in this area that he hasn't shared yet.
So this article can be classed as a debugging introduction and then we can do specific more advanced stuff fit for more experienced users.
Re: Flowstone Guru Blog
Posted: Sun Oct 12, 2014 12:33 pm
by Youlean
Hey Exo, I think that you should add detail guide for how to optimize plugins memory usage, opening speed, performance...
Re: Flowstone Guru Blog
Posted: Sun Oct 12, 2014 1:41 pm
by Exo
Youlean wrote:Hey Exo, I think that you should add detail guide for how to optimize plugins memory usage, opening speed, performance...
Yes I will do something like this. I was thinking separate blog posts for loading times and CPU performance ect.. and then probably wrap the posts up into one big PDF.
Re: Flowstone Guru Blog
Posted: Tue Oct 14, 2014 7:48 pm
by KG_is_back
Hello, people! This week on Flowstone guru blog we will have a look at the Assembler component and it's use in flowstone. The article will come out in 4 parts (one per day) and will hopefully cover everything you'll ever need to know about assembler and flowstone. The articles should be interesting to both total numbs as well ass skilled "flowstoners" they expect some basic DSP code component knowledge though.
Today the first part "
introduction" should cover the background of watta hell is assembler
Re: Flowstone Guru Blog
Posted: Tue Oct 14, 2014 9:25 pm
by kortezzzz
Thanks guys, you are doing an amazing job. Asm was allways an enigma for most of us. Cant wait to read this

Re: Flowstone Guru Blog
Posted: Tue Oct 14, 2014 10:05 pm
by KG_is_back
kortezzzz wrote:Thanks guys, you are doing an amazing job. Asm was allways an enigma for most of us. Cant wait to read this

Yes, thanks... when I first read the whole thing finished (I have all the four parts prepared) I immediately realized it is the "I wish someone else wrote this 5 years ago when I was beginner"-type of thing. ASM in flowstone is poorly documented (along with DSP code which does not even have a complete list of features in the manual) and because of limited opcode list also slightly different from normal assembler. Hopefully this article will give some light into these gray areas.