Bugs in the editor 2.41 beta

Hi,

now on the bugs in the editor (I am non-US using Windows XP SP2 - and in my country we use "," for the decimal point):

1) Segment 1 is overwritten randomly while editing. Any segment can - it seems - overwrite segment 1. I have an idea ,that this happens when I save the session during editing work. And that the last segment I was editing before saving does the overwriting.

2a) The decimal problem was not really solved with the 2.41 beta editor for us non-US people. OK the content of each segment now shows "," - but you can't any longer input data right into each segment. Input has now to be done just and only into the common input-fields right above the segments. And those input fields still don't accept anything but "." for a decimal point.

2b) One more thing happened while trying to solve the decimal point in editor 2.41 beta. The input fields are not any longer as "fool proof" as they used to be. If one tries inputting a too large number for a given field - the editor simply collapses. This is not a new problem but now less fields are "fool prooof ". My guess is that the "fix" of the decimal problem was to "cut" the input boxes, which alowed input directly into each segment. And if I were the programmer I would have built the "fool proof test" right into those input boxes. So probably the boxes left and the "fool proof thing" with them.

3) When editing long sessions (i.e. so long that you will need the scroll bar to the right) the editor randomly looses count of what segment it is pointing at and so what segment it is editing. This often means that editing seems to go on where you think you are - but somewhat later some not intended segments were in reality edited.

4) I always use the pull down editing menu. Especially since stange things happened using the command line button "Delete Segment". I guess the real problem is the editor loosing count of where it is. I now use just and only the pull down meny "Cut" command instead. That is stable.


Kind Regards

MindMan

Hi Mind Man,

I just wanted to let you know that your message has been forwarded to the software designer of this program and hopefully we'll have an answer for you soon.

M.

I'm looking at the problems.
I'll post some code for the decimal separator issue soon.
Slogged through the help files and found a promising approach.
I haven't been able to coerce my PC into thinking it's not from the US so I can't test it directly.

Hello MindMan,

I've been working on version 2.42 of the Editor and have some things to test.
I've attached ?Proteus2_42.zip? (which is just a zipped form of ?Proteus2_42.exe?) to this post. You should be able to unzip it and paste it into the old application directory? no need to uninstall and reinstall. You may have to upgrade any shortcuts to point to the 2.42 version rather than the 2.41.

Only the window application has been changed so you don?t have to upload any OS into the Proteus.
***********
I can't test the code for the "," decimal separator so see if it works when setting the LFO1 and LFO2 frequencies. Hopefully even dragging the slider should update things with a ",".

I've added a log file (with minimal functionality at the moment) but one of the first things it does is tests the response to assigning numeric values to "2.34? and ?2,34?. After the test it writes to the log if your system is using a ? , ? or ? . ? as a decimal separator. There is a possibility that neither works in which case the log will show a ? * ?.
If you type in something like ?k4? into the LFO1 & 2 areas you should hopefully see the edge of your application window flash red, green and blue indicating the programming found that ?k4? caused an error when trying to be converted to a numeric value. If the log is open it will print the error to the log. You may see the border flash at other times (usually when the segment pointer is out of sorts). These events are also logged.

You can start/stop the log by clicking <Help> <Start Log File> or <Close Log File>. After closing, it will be saved in the application directory as ?Proteus_LOG.PRL?. It is continually overwritten each time you open the log so if you want to save one for future reference you have to rename it.

The new windows app also has a fix for the "incorrect session time reported" when a session has special segments in it.

I found an instance of the segment pointer getting set to "1" after a "Save As" operation (which also occurs when you save a new session for the first time). Hopefully this corrects the random overwrite of segment one.

As far as fool proofing data entries, I had to strip out the code when I was trying to get the program to recognize non-US numerical formats. Once that is going, I?ll start putting the ?edit as you go? code back into the program.

Let me know how it goes.

Best regards,
TheRock

Hi TheRock,

I have dowbloaded the file.

I will test it during the next 24 hours by writing a minir session.

Kind Regards

MindMan

Hi TheRock,

I tried to open one of my older sessions with "," as the decinal point.

All I did was to step from the first segment and one segment down at a time. Each time I stepped on the next segment - the editor interpreted the "," as not being there.

I.e. a start LFO-frequency "17,1 Hz" was interpreted as 171 Hz inside the editor and as 50 Hz in the input fielld above the segments.

The second time I started the log first. I attach it ( I renamed it to *.txt due to the upload rules here). I will attach my european session as well (a non-destroyed version).

At this stage the editor behaves very much like the 2.3 and pre 2.3 versions.

I don't know how a US Windows XP is functioning - but I can make my european one behave like a US one - if I go to the control panel and change the so called language settings. This affects of course all software - and is why I am not happy with it. Maybe you can do the same on your pc?

Kind Regards

Morten

Hi MindMan,

Thanks for the feedback.

Bummer!

Best make a backup folder of all your sessions and use that until this thing gets squared away.
**********
The US version does the same thing with ?17,1? ? changes it to 171.

What happens when you scroll with the slider?

Did you make a log file and look at what the decimal separator was?

I tried using the language settings and while the time and date changed I didn?t see any use of the ?,? as a decimal separator. I?ll give it another shot.

Again, thanks for your help.

Best regards,
Todd

Hi,

I must honestly say, that I never made it to the slider.

The slider doesn't misbehave each time, but just sometimes during editing - and I could not really make myself "work" with the editor for a longer time - while it mashes my sessions all along.

If you are stuck I might go for a new session with no decimal points at all. Just to put the editor under pressure - while ignoring the decimal problem.

I will, however, be on holidays for most of july.

K.R.

MindMan

Hi,

I started the log and tried to input some new decimals.

Hard to describe what happened - but if I changed a segment - then sometimes I got the "50 Hz" all at once. Sometimes when editing not hte next but the next again segment. I.e. "correction seems not to happen in one shot each time.

I even suceeded in quite a lot of decimals down to 1/1000 - which the editor officially does not support.

The log (did I send the wrong one first time?) and mashed session comes here.

K.R.

MndMan

Hi MindMan,

I changed my regional language settings to German (Luxembourg) and can now work with the ?,? separator. Things should go smoother now.

I noticed that when I use the ?comma? on the regular keyboard (next to the ?M?) the program accepts the value okay, but if I use the ?decimal point? on the numeric keypad (below the ?3?) then it is entered as a ?.? and is misinterpreted. How does it work on yours?
I also see different programs respond to the numeric separator differently?
?Calculator? seems to accept it okay but ?Visual Basic?, ?Word 2000? and even typing into this field convert it to a ?.?. Weird!

Does your numeric keypad show a ?.? or a ?,? for the decimal separator?
When you use that key does it print as a ?.? or a ?,? on the screen.
Windows does the interpretation of the keystrokes and passes the value onto the application but I can intercept them and change them if needed. That will be my next approach.

Best regards,
Todd

Hi,

my numeric keypad shows a ",".

There is no difference (same faulty things happen) whether I use that or the one next to the "m".

I have, however, noticed:

First time I go into a healthy session and move onto a segment say "24,3" Hz - the segment is unchanged. But the common input field allready says "50" i.e. it sees 243 Hz, which is too large. When I step to the next segment the change to 50 takes place.

K.R.

MindMan

Hi MindMan,

Here's another shot at the decimal separator (DS)? Proteus2_43.zip.

The application will do it?s best to decipher any text string that is entered.
You should be able enter either a ?.? or a ?,? and have it converted to the regional standard.
You should be able to enter useless characters and the application will ignore them while doing a left to right analysis of the string.

In general these are the rules that will be followed?
1) The only printable characters that will be processed are ?0? ?1? ?2? ?3? ?4? ?5? ?6? ?7? ?8? ?9? ?,? ?.? and ?:? when editing the segment time.
2) The first instance of the left most ?regional? DS will be used: all others are ignored.
3) If a ?regional? DS is detected then all non-regional DS?s are ignored.
4) If no ?regional? DS is detected then first left most non-regional DS?s (if it exists) will be used and converted to a ?regional? DS: all others will be ignored.
5) LFO #1 (and #2) entries are rounded to the nearest 10th .
6) Decimals entered in the Brite or Sound Pitch boxes will be rounded to the nearest integer.
When editing the Time textbox?
7) Any ?,? or ?.? to the left of the ?:? is ignored.
8) The value to the left of the ?:? is treated as the minute?s value (20 minutes maximum).
9) The value to the right of the ?:? is treated as the second?s value. Values >= 60 will be reduced by 60 and the minute?s value will be incremented accordingly (20 minutes maximum).
10) Any decimal entered will be set to ?x:xx,0? if the decimal value is less than ?,5? otherwise it is changed to ?x:xx,5?.

If all goes well you should be able to do the following when using the ?,? or ?.? decimal separator.
Type ?2.3,4,7.5? in the LFO #1 (or #2) text boxes; the entry changes to ?23,4? or ?2.3?
Type ?2.36? in the LFO #1 (or #2) text boxes; the entry changes to ?2,4? or ?2.4?
Type ?4? in the Time text box; the entry changes to ? 0:04,0? or ? 0:04.0?
Type ?4:? in the Time text box; the entry changes to ? 4:00,0? or ? 4:00.0?
Type ?4:,5? in the Time text box ; the entry changes to ? 4:00,5? or ? 4:00.5?

Hope this works on your machine.

Best regards,
TheRock

Hi TheRock,

all we have been discussion so far seems to be OK now.

1) The editor seems not any longer to loose track of what segment it is pointing at

2) Segment 1 is not any longer overwriten

3) All input fields - except the time stamp - seem to be foolproof

4) The time stamp seems somewhat unstable.

a) at new sessions most is OK

b) at sessions - which I wrote - while asking my XP behave like a US-one - the time stamp goes from XX:YY.Z to XX:YY,Z the first time I put the cursor into the time box. The stamp moves one place to the right as well. I guess this is a fault by my XP not your software, as new sessions made by your newest editor start at XX:YY,Z from day one

The unstable thing regards inputting - into the time box - first "4" [ENTER] and then in the same box a "4:". You then get an non OK number. See last segment in the attachment.


Kind Regards

MindMan

Hi MindMan,

Here is Proteus2_44.zip.
It makes sure the integer part of the second?s entry is two characters long (after reducing any number > 59).
It also makes sure there is one character to the right of the decimal separator. It will add a ?0? if none is present.

Best regards,
TheRock

Hi TheRock,

I can't pinpoint any more bugs in the ordinary part of the editor.

I suggest we let that part rest - if OK by you. Maybe some other guy finds some more?

For good sake I took a short look at the "Supplemental Proteus Controls". Something not so good has happened there. I hardly ever use that part, so I don't really remember what it is all expected to do. Must be in the manual. Something has happened all around. It feels as though the sliders somehow limit the supposed input? I only use LF1 / LF2 and they used to allow frequency down to 0.01 Hz. The slider is much more large-stepping.

My feeling is that this is so for the rest as well.

I go on holidays now. Maybe it is time to put forward the editor?

Thank you for the good show. I hope that you didn't feel pushed by me.

I never have used the rest of the editor. Especially the part for Thoughtstream - though I own one. Maybe something was affected there as well (like with the "Supplemental Proteus Controls"). I can't help on that one.

Kind Regards

MindMan

Hi MindMan,

While the lower limit of the "Supplemental Proteus Controls" is 0,2 Hz you can increment the value in 0,01 Hz steps.
I see the default increment is 1,0 Hz.
If you hold down the "Ctrl" Key while scrolling you get 0,01 Hz steps.
If you hold down the "Shift" Key you get 0,1 Hz steps.
If you hold down the "Shift" and "Ctrl" Key you get 10,0 Hz steps.
This is not very intuitive.

I am thinking of changing it to be more like the main editor...
No keys down would give the finest steps ?(0,01 Hz)
The "Ctrl" key would give a little less precision ?(0,1 Hz) steps.
The "Shift" key would give the next level ?(1,0 Hz) steps.
And both keys would give largest steps ?(10,0 Hz).

As far a feeling pushed. I didn't feel that way.
I was actually impressed at your thoroughness.
Your observations on what caused an error made it much easier to track down the bug.

Have a good time on vacation.

Best regards,
TheRock

Hi,

I have a suggestion.

The reason that people like me want to use the "Supplemental Proteus Controls" is that they want more presision than the main editor offers.

Therefore it is meaningless to offer less precision inside the "Supplemental Proteus Controls".

If I should want a mixture of normal and extra precission in a given segment I would - hopefully intuitive - do the following.

1) I edit all with normal precision in the ordinary segment.
2) I then in the ordinary segment "mark" (working area in top of the editor) the type of detail I would like more precision of.
3) I then install a supplemental "line" onto the segment.
4) I edit the supplemental "line" with the wanted more precise data

In general if think the "supplemental controls" should just and only increase precision with a factor around 10. I don't know what you have promised your customers - I must say. I happened to notice a max pitch of 999.9. Maybe 999 is OK as max. I know some people want this type of high pitch - though it sounds awfull.

And one more probably more usefull suggestion on the "Supp. Prot. Com.": Why are the dual binaural beats so limited. Nearly nobody looking for "DBB" would want to limit himself to a range of 1/2 - 2/3 - 3/4 - 4/3 - 3/2 - 1???
Could this be more smooth stepping?

And may you have a good time on vacation as well.

K.R.

MindMan

Hi,

you may give this some thought as well:

Problems with serial-to-USB converters

To make mine run (and I am lucke I understand) I inside the editor have to force the tranmission speed really low. Actually to the end of the slider.

Maybe your software in the editor or Proteus needs adjustments regarding this problem as well. The hight speed end of the slider is not much in use any longer.

K.R.

MindMan

Quote:

---

Originally Posted by MindMan

Hi,

you may give this some thought as well:

Problems with serial-to-USB converters

To make mine run (and I am lucke I understand) I inside the editor have to force the tranmission speed really low. Actually to the end of the slider.

Maybe your software in the editor or Proteus needs adjustments regarding this problem as well. The hight speed end of the slider is not much in use any longer.

K.R.

MindMan

---

The software works fine with my Proteus at the higher speed. I think it may come down to the differences between adaptors and drivers.

Quote:

---

Originally Posted by TheRock

Hi MindMan,

Here is Proteus2_44.zip.
It makes sure the integer part of the second?s entry is two characters long (after reducing any number > 59).
It also makes sure there is one character to the right of the decimal separator. It will add a ?0? if none is present.

Best regards,
TheRock

---

Thank you for 2.4.4 upgrade but Time to end of selected Segment does not agree with reality and Total Session Time also. E.g. when I play Run Segment 80:00.0 then Time to end of selected Segment is permanenetly 00:10:05 and Total Session Time is also 00:10:05 constantly.

Best regards,
atrance

Please try v2.45 to check if this is a problem that has already been addressed. I'm not certain whether an 80 minute segment is possible.

Hi,

each segment can officially be up to 20 minutes long.

There is however some rounding error or bug somewhere - as for instance three segments of each 20 min. give a total preset time of less that 60 minutes.

I have also noticed some problems with the new editor regarding inputting time as seconds. I don't know if this is official but in earlier versions an input of say 100 [ENTER] resulted in 1 minute and 40 seconds. A fast and smart way of inputting munutes and seconds in one go. 20 minutes would be 1200 [ENTER] - but this seems not to be an acceptable path any more.

K.R.

MindMan