From the original SynthMaker forum (2004–2014), with its members’ names and dates.
aliasant ·
Code, AssemblyCode and Text all need scrollbars. Or something ...
Was just trying to optimize a long assembly code and had to scroll to the beottom, change somethingm click otside to hear the effect and then the Assembly Code scrolled back to the beginning so when I realized that the change I did wasnt so good I had to scroll down to try and find it.
Wouldnt this be better with some kind of scrollbar or maybe just that it doesnt jump back to the beginning everytime I click outside the prim..
MyCo ·
+1 vote from me 🙂
sunsynth ·
add one stroke 😉
oddson ·
[old link]
aliasant ·
Ooops =)
exonerate ·
I still don't think the code modules should have scroll bars,
The code modules just need to keep there scroll position when you click outside them.
Also if you are just clicking outside to compile the code so you can hear the changes, theres an option to 'compile as you type' (never actually used it though myself) , i think this would mean you don't need to click outside to compile therefore losing your scroll position. I can imagine it making the code module slower to type in though.
cheers 😉
Exo
aliasant ·
exonerate wrote: I still don't think the code modules should have scroll bars,
The code modules just need to keep there scroll position when you click outside them.
Also if you are just clicking outside to compile the code so you can hear the changes, theres an option to 'compile as you type' (never actually used it though myself) , i think this would mean you don't need to click outside to compile therefore losing your scroll position. I can imagine it making the code module slower to type in though.
cheers 😉
Exo
Well. The scrollbar would also indicate how long/big the text/code is.
But I would hate if it looked like the general windows scrollbar.
THe most important in this topic is that it should stay were it is when clicked outside.
And the option to execute the code while typing is not a way around it.
Most of the times I think you want to do a few changes before actually execute the new code. Or ?
infuzion ·
aliasant wrote:
exonerate wrote: I still don't think the code modules should have scroll bars, The code modules just need to keep there scroll position when you click outside them.
The scrollbar would also indicate how long/big the text/code is.... THe most important in this topic is that it should stay were it is when clicked outside.
A scroll bar would help to judge code length; some of my ASM listings are 100+ lines long!
A good idea, but low low priority, since one could just copy/paste into editor/copy/paste into SM like I do sometimes. Bigger fish to fry IMHO.
But still a cool idea 😀
TomC ·
aliasant wrote: THe most important in this topic is that it should stay were it is when clicked outside.
+1.
Yesterday I double-checked 2 long asm modules against each other.
Not fun if you don't want to work outside SM.
Tom
bootsy ·
+1
jobro ·
infuzion wrote: A scroll bar would help to judge code length; some of my ASM listings are 100+ lines long!
A good idea, but low low priority, since one could just copy/paste into editor/copy/paste into SM like I do sometimes. Bigger fish to fry IMHO.
But still a cool idea 😀
And there we have the issue of double work. 🙂 You copy the code text to get an estimation how large your code is, then you would have to alter the code within your other editor and repaste it in SM. That is in the best of cases a huge waste of time when you could do the same thing with proper scrollbars. The scrollbars also shows where you are in the code + makes it alot easier to navigate around in your code. Right now you have to press the arrow keys to scroll around, and that ain't pretty acurate. Let me guess: You used EDLIN in MSDOS? 🙂
infuzion ·
jobro wrote:
infuzion wrote: ...one could just copy/paste into editor/copy/paste into SM like I do sometimes.
And there we have the issue of double work. 🙂 You copy the code text to get an estimation how large your code is, then you would have to alter the code within your other editor and repaste it in SM. That is in the best of cases a huge waste of time...Let me guess: You used EDLIN in MSDOS? 🙂
Not long at all:
1) Ctrl+a, Ctrl+c inside SM ASM
2) Open your fast text editor, turn on SM ASM highlighting, switch to MAC line delimition if you need to
3) Ctrl+v
4) edit faster & better since you can see more of the code at once, have bookmarks, macros, tweak the highlighting as you want, search & replace the entire code, online command reference, etc
5) Ctrl+a, Ctrl+c
6) Tab to SM
7) go into the ASM primitive
8) Ctrl+a, Ctrl+v
Net time: 2 minutes saved (not lost) because of the time saved using search & replace, not to mention faster code since you can find unused an xmm, etc.
Also, the scroll wheel scrolls just fine inside the Code/ASM editors, as do Page Up/Down.
So, what is the problem? Really, SSE2-3 would be a better improvement than Code/ASM scrollbars. For that matter, IMHO middle mouse button would be easier to add to SM, & more useful.
& I used MSDOS edit, & about 30 other editors from the ones on Timex Sinclairs, Sun Sparcs, IBM mainframes, etc.
aliasant ·
infuzion said with a firm voice.
Not long at all:
1) Ctrl+a, Ctrl+c inside SM ASM
2) Open your fast text editor, turn on SM ASM highlighting, switch to MAC line delimition if you need to
3) Ctrl+v
4) edit faster & better since you can see more of the code at once, have bookmarks, macros, tweak the highlighting as you want, search & replace the entire code, online command reference, etc
5) Ctrl+a, Ctrl+c
6) Tab to SM
7) go into the ASM primitive
8) Ctrl+a, Ctrl+v
Net time: 2 minutes saved (not lost) because of the time saved using search & replace, not to mention faster code since you can find unused an xmm, etc.
Also, the scroll wheel scrolls just fine inside the Code/ASM editors, as do Page Up/Down.
So, what is the problem? Really, SSE2-3 would be a better improvement than Code/ASM scrollbars. For that matter, IMHO middle mouse button would be easier to add to SM, & more useful.
Well. To me that list is way to long.
It might be ok to work like that if I knew what I was doing but I dont so I have to guess what would be a good add or remove from a code.
So if I have to use this method, working outside SM then copy and paste back my guesses into SM. Click outside to activate the changes... realize that the changes was not what I had hoped for... then start all over again....
To me this is PC think. A Mac user would never accept this in an application.
And I think comparing SSE2-3 with adding scrollbars is a bit off.
I agree that it is much more important thing to add to SM but I also believe its much much more work involved.
Adding scrollbars should be a 5 minutes job. Would probably take a bit longer but not much.
How many days/weeks it would take to add then SSE2-3 function I have no idea about.
infuzion ·
aliasant wrote: Well. To me that list is way to long. It might be ok to work like that if I knew what I was doing but I dont so I have to guess what would be a good add or remove from a code. So if I have to use this method, working outside SM then copy and paste back my guesses into SM.
That is true, you have to be used to SM's Code/ASM... but if you're not used to it, it might be better to split the Code into smaller segments in a few Code primitives, then it will be easier to mentally manage, test, & to edit. And trust me, if you're doing some serious ASM reduction on a large piece of code, you're not likely going to change 1 line at a time; you have to edit 4-20 lines at once, so a global search & replace in an editor is more useful.
My point of vs-SSE2 is that there are existing workarounds for not having scroll bars, but none for wanting 64bit audio.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker