codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Infinite loop checking potentiometer

Wed Feb 21, 2018 11:31 pm

Hello,

I want to read a potentiometer continuesly and use the output in the script to execute a file.

Code: Select all

#!/usr/bin/python
# -*- coding: utf-8 -*- Simple example of reading the MCP3008 analog 
# input channels and printing them all out. Author: Tony DiCola License: 
# Public Domain
import time
import subprocess
import Adafruit_GPIO.SPI as SPI
import Adafruit_MCP3008

SPI_PORT = 0
SPI_DEVICE = 0
mcp = Adafruit_MCP3008.MCP3008(spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE)
while True:
 pot0 = str(mcp.read_adc(0) * 16)
 time.sleep(0.0001)
 subprocess.call("./sendmidi dev f_midi pb " + pot0)
Ive written code and it works. BUT it only works fast whenever i first suspend the script with ctrl-Z and then run it again. If i dont do that the script Will run much slower. Any Idea why?

Paul Hutch
Posts: 311
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA

Re: Infinite loop checking potentiometer

Wed Feb 21, 2018 11:39 pm

It may be that your loop is too tight (0.0001 = 0.1ms) so other OS processes are falling too far behind their desired schedules. Try changing your sleep time to (0.01) 10ms which will still give a response about 10 times faster than a human can detect or react.

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Wed Feb 21, 2018 11:47 pm

Ive tried that too but its the same result:/ after unpausing it it runs great. could it also be that the file executing needs to run async?

Paul Hutch
Posts: 311
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA

Re: Infinite loop checking potentiometer

Thu Feb 22, 2018 12:01 am

I hadn't even noticed that you where spawning another thread on each time through. That waits for the other command to complete so the sleep lenght isn't much of a factor if the called program takes a significant amount of time to run.

I'd try commenting out the subprocess.call() line, add a print of the pot's value in it's place, set the sleep to 0.01 then let it run for a while and see if it keeps running fast.

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Thu Feb 22, 2018 6:47 am

I hadn't even noticed that you where spawning another thread on each time through. That waits for the other command to complete so the sleep lenght isn't much of a factor if the called program takes a significant amount of time to run.
Is there a way to proper execute this file without waiting till it is finished? I think the async Will help
Paul Hutch wrote:
Thu Feb 22, 2018 12:01 am
I'd try commenting out the subprocess.call() line, add a print of the pot's value in it's place, set the sleep to 0.01 then let it run for a while and see if it keeps running fast.
Yes It runs fast now when only using print()

Paul Hutch
Posts: 311
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA

Re: Infinite loop checking potentiometer

Thu Feb 22, 2018 3:22 pm

Since you now know the issue is caused by calling that external program, I suggest trying out a native Python MIDI library to avoid the extra overhead of calling a separate program.

To be clear I have never worked with MIDI in any way and I have no idea if there are fully functional MIDI libraries for Python. However my experience has been that there are usually multiple Python libraries available to do almost anything.

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Thu Feb 22, 2018 3:50 pm

You probably need to re-think yoyr whole approach as you're currently flooding the MIDI bus with more messages than it can cope with. Well at least with your original value for sleep.

Making the subprocess asychronous might make your loop faster but it won't solve that issue and may make the overall performance worse as you'll end up with a lot of queued and/or competeing threads. Potentially 10,000 per second which is roughly three times the messages MIDI can cope with leaving no bandwidth for anything else. It takes time to spawn a process and to send the message so you'll be generating threads faster than they execute.

Check whether the device(s) on the other end of the MIDI link need to be continuously updated with the pot value. If they don't, consider sending the MIDI message only when there is significant change to the value read from the pot.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

User avatar
OutoftheBOTS
Posts: 674
Joined: Tue Aug 01, 2017 10:06 am

Re: Infinite loop checking potentiometer

Thu Feb 22, 2018 10:58 pm

This is my take on your problem. Your trying to do a very simple task in a very complex way.

Multi processing is very complex.

Here's the simple task that you want to do:
1. read a ADC
2. send mini message
3. time delay
4. repeat

my suggestion would be to look for python code that will let you send the mini message from with in you program rather than spawn a new process then continue to run your program in parallel to the new spawned process.

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 12:47 pm

OutoftheBOTS wrote:
Thu Feb 22, 2018 10:58 pm
This is my take on your problem. Your trying to do a very simple task in a very complex way.

Multi processing is very complex.

Here's the simple task that you want to do:
1. read a ADC
2. send mini message
3. time delay
4. repeat

my suggestion would be to look for python code that will let you send the mini message from with in you program rather than spawn a new process then continue to run your program in parallel to the new spawned process.
That's what the OP is doing. Just using an external process to send the message. There is no multi-processing going on.

The OP appears to have an unrealistic idea of how long it takes to execute a line of code and how much bandwidth is available on a MIDI link. Moving from an external program to a python library won't change that. To be absolutly clear at the risk of preaching to the converted, one line of python != one cpu instruction != one clock cycle.

As mentioned above, the time delay is so short that it will make next to no difference. What most affects the speed of the loop is the time it takes to read the ADC and the time it takes to send the MIDI message.

The OP's approach is flawed. It boils down to loop as fast as possible and once each pass read the ADC and send a MIDI message. There are a number of problems with this:
  • It will eat CPU cycles preventing anything else from running
  • It will flood the MIDI bus with messages allowing nothing else to send messages
  • Continuous updates are likely not needed, just send an update when the value from the pot changes
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 12:56 pm

thagrol wrote:
Fri Feb 23, 2018 12:47 pm
Continuous updates are likely not needed, just send an update when the value from the pot changes
Yes i want to do that but i dont know how to check if the value has changed. I tried:
  • Read value
  • time out for a bit
  • Read again
  • Compare with x - y
  • check if different is Greather than ex 10
but it went weird (negative values) and i dont know any other proper way to do this.

-i use a Raspberry pi zero w as midi gadget via USB so i dont know if that could be sending faster signals.

scotty101
Posts: 3236
Joined: Fri Jun 08, 2012 6:03 pm

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 1:33 pm

Negative values are expected.. This just means that the new value is smaller than the previous value. You could use the abs function to only get positive values.

The code below subtracts the current from the last value and if the difference between the two is greater than 10, it will do something.

Code: Select all

if abs(currentValue - lastValue) > 10:
    send_current_value(currentValue)
    lastValue = currentValue # Update the lastValue for the next check.
Electronic and Computer Engineer
Pi Interests: Home Automation, IOT, Python and Tkinter

Paul Hutch
Posts: 311
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 2:05 pm

thagrol wrote:
Fri Feb 23, 2018 12:47 pm
The OP appears to have an unrealistic idea of how long it takes to execute a line of code and how much bandwidth is available on a MIDI link. Moving from an external program to a python library won't change that. To be absolutly clear at the risk of preaching to the converted, one line of python != one cpu instruction != one clock cycle.

As mentioned above, the time delay is so short that it will make next to no difference. What most affects the speed of the loop is the time it takes to read the ADC and the time it takes to send the MIDI message.
You may have missed message 3 where codGmer says he tried my suggestion of changing the sleep from 0.0001 to 0.01 (100 times slower) and it made no difference. This leads me to believe either MIDI messages need to be more than 10 ms apart or something else around the act of calling an external binary to send the message is causing his problem.

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 5:11 pm

Paul Hutch wrote:
Fri Feb 23, 2018 2:05 pm
thagrol wrote:
Fri Feb 23, 2018 12:47 pm
The OP appears to have an unrealistic idea of how long it takes to execute a line of code and how much bandwidth is available on a MIDI link. Moving from an external program to a python library won't change that. To be absolutly clear at the risk of preaching to the converted, one line of python != one cpu instruction != one clock cycle.

As mentioned above, the time delay is so short that it will make next to no difference. What most affects the speed of the loop is the time it takes to read the ADC and the time it takes to send the MIDI message.
You may have missed message 3 where codGmer says he tried my suggestion of changing the sleep from 0.0001 to 0.01 (100 times slower) and it made no difference. This leads me to believe either MIDI messages need to be more than 10 ms apart or something else around the act of calling an external binary to send the message is causing his problem.
Im not sure about that, i think it is a OS problem or something. The evidence I have for that is that after i have Paused the script with CTRL - Z a couple of times it works flawlessly and smooth. Look at this gif explaining, watch the control knob closely: https://gyazo.com/430bc69685abceeda271de6cf2c099de

and here are the comparison between slow running script and fast script after CTRL - Z ing a couple of times.

Here's the slow running code:
https://i.gyazo.com/e1a9d70cf433668794a ... 4c7973.mp4

here's the fast running code:
https://i.gyazo.com/2599f4e6ca9b146b55d ... 937a64.mp4

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 5:29 pm

Paul Hutch wrote:
Fri Feb 23, 2018 2:05 pm
thagrol wrote:
Fri Feb 23, 2018 12:47 pm
The OP appears to have an unrealistic idea of how long it takes to execute a line of code and how much bandwidth is available on a MIDI link. Moving from an external program to a python library won't change that. To be absolutly clear at the risk of preaching to the converted, one line of python != one cpu instruction != one clock cycle.

As mentioned above, the time delay is so short that it will make next to no difference. What most affects the speed of the loop is the time it takes to read the ADC and the time it takes to send the MIDI message.
You may have missed message 3 where codGmer says he tried my suggestion of changing the sleep from 0.0001 to 0.01 (100 times slower) and it made no difference. This leads me to believe either MIDI messages need to be more than 10 ms apart or something else around the act of calling an external binary to send the message is causing his problem.
Nope I saw that. To keep things clear for late comers to the thread it was a deliberate decision to stick with the delay value from the OP's posted code.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 5:52 pm

codGmer wrote:
Fri Feb 23, 2018 5:11 pm
Paul Hutch wrote:
Fri Feb 23, 2018 2:05 pm
thagrol wrote:
Fri Feb 23, 2018 12:47 pm
The OP appears to have an unrealistic idea of how long it takes to execute a line of code and how much bandwidth is available on a MIDI link. Moving from an external program to a python library won't change that. To be absolutly clear at the risk of preaching to the converted, one line of python != one cpu instruction != one clock cycle.

As mentioned above, the time delay is so short that it will make next to no difference. What most affects the speed of the loop is the time it takes to read the ADC and the time it takes to send the MIDI message.
You may have missed message 3 where codGmer says he tried my suggestion of changing the sleep from 0.0001 to 0.01 (100 times slower) and it made no difference. This leads me to believe either MIDI messages need to be more than 10 ms apart or something else around the act of calling an external binary to send the message is causing his problem.
Im not sure about that, i think it is a OS problem or something. The evidence I have for that is that after i have Paused the script with CTRL - Z a couple of times it works flawlessly and smooth. Look at this gif explaining, watch the control knob closely: https://gyazo.com/430bc69685abceeda271de6cf2c099de
If I interpret that gif correctly, which is difficult as it loops, your ./sendmidi script isn't getting called: you're getting "sh: 1: ./sendmidi not found"

I'm also not entirely sure what you're actually doing. It looks to me like you're starting your script, hitting ctr-C (which likely kills it), hitting crt-Z (which likely does nothing as your script has been killed), then finally starting a new copy of your script.

Starting a new copy will leave any paused copy in the background. It does not cause a paused script to resume.

To resume a paused app use

Code: Select all

fg
or if you have more than one use

Code: Select all

jobs
fg %n
where n is the job number of the app reported by "jobs"

As for why performance would get better with more copies of the process in memory I have no idea.

Oh, and why are you doing

Code: Select all

cd /
before running your code?
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 6:01 pm

thagrol wrote:
Fri Feb 23, 2018 5:52 pm

If I interpret that gif correctly, which is difficult as it loops, your ./sendmidi script isn't getting called: you're getting "sh: 1: ./sendmidi not found"
yes it was because i was running the script from a different directory which has no file called sendmidi, thats why i needed to change to / because i have the script in the root (from any location it is slow thats why i tried the root)
thagrol wrote:
Fri Feb 23, 2018 5:52 pm
I'm also not entirely sure what you're actually doing. It looks to me like you're starting your script, hitting ctr-C (which likely kills it), hitting crt-Z (which likely does nothing as your script has been killed), then finally starting a new copy of your script.
Im hitting ctr-Z, and then open a new copy.
thagrol wrote:
Fri Feb 23, 2018 5:52 pm
As for why performance would get better with more copies of the process in memory I have no idea.

Im thinking about this and maybe it is because i dont run the sendmidi file with a & behind it, i tried it half an hour ago and i saw some different result (faster) i have to test this out more why this happens.

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 6:30 pm

codGmer wrote:
Fri Feb 23, 2018 6:01 pm
thagrol wrote:
Fri Feb 23, 2018 5:52 pm

If I interpret that gif correctly, which is difficult as it loops, your ./sendmidi script isn't getting called: you're getting "sh: 1: ./sendmidi not found"
yes it was because i was running the script from a different directory which has no file called sendmidi, thats why i needed to change to / because i have the script in the root (from any location it is slow thats why i tried the root)
thagrol wrote:
Fri Feb 23, 2018 5:52 pm
I'm also not entirely sure what you're actually doing. It looks to me like you're starting your script, hitting ctr-C (which likely kills it), hitting crt-Z (which likely does nothing as your script has been killed), then finally starting a new copy of your script.
Im hitting ctr-Z, and then open a new copy.
Which as I said is bad and doesn't do what you seem to think it does. You'll have multiple copies of your process in memory, most of them paused. You can see how many via the "jobs" command
Im thinking about this and maybe it is because i dont run the sendmidi file with a & behind it, i tried it half an hour ago and i saw some different result (faster) i have to test this out more why this happens.
From the python 3 docs for subprocess.call: "Run the command described by args. Wait for command to complete, then return the returncode attribute."

subprocess.call won't return until the command completes so the time taken by your sendmidi tool is likely what's slowing down your loop. Adding "&" or othewise making that call asynchronous will make your loop faster but, as I mentioned above, will spawn a lot of subprocesses probably faster than they can execute.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

Paul Hutch
Posts: 311
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 9:29 pm

thagrol wrote:
Fri Feb 23, 2018 6:30 pm
subprocess.call won't return until the command completes so the time taken by your sendmidi tool is likely what's slowing down your loop.
We have now come full circle, that's what I said and he ran the test I suggested which proved it was the where the slowdown happened (messages up to #6).

Since we now seem to have consensus on what is causing the slowdown, I'll again suggest trying a native Python MIDI library to avoid the slowdown from making an OS call to an external binary. Also set the sleep value for the loop at 0.1 to start with and then decrease it only if the reaction speed is too slow.

User avatar
OutoftheBOTS
Posts: 674
Joined: Tue Aug 01, 2017 10:06 am

Re: Infinite loop checking potentiometer

Fri Feb 23, 2018 9:44 pm

That's what the OP is doing. Just using an external process to send the message. There is no multi-processing going on.
The line of code

Code: Select all

 subprocess.call("./sendmidi dev f_midi pb " + pot0)
Does exactly that. It spawns a new multi process (not a new thread but a whole new process). This is the same as being on a windows computer and opening a new window and starting a new program running as a multi task (multi process).

So every time you execute subprocess.call you will be opening a new separate program as a multi task.

A quick google of python midi found many hits and the first that I clicked was this one https://mido.readthedocs.io/en/latest/

Something like this library will allow you to send you midi message from with in your python program without needing to open an external multi process

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 1:46 pm

Paul Hutch wrote:
Fri Feb 23, 2018 9:29 pm
thagrol wrote:
Fri Feb 23, 2018 6:30 pm
subprocess.call won't return until the command completes so the time taken by your sendmidi tool is likely what's slowing down your loop.
We have now come full circle, that's what I said and he ran the test I suggested which proved it was the where the slowdown happened (messages up to #6).

Since we now seem to have consensus on what is causing the slowdown, I'll again suggest trying a native Python MIDI library to avoid the slowdown from making an OS call to an external binary. Also set the sleep value for the loop at 0.1 to start with and then decrease it only if the reaction speed is too slow.
Indeed. We've both tried to point out that spawning a process takes time, as does sending a MIDI message). The OP doesn't seem to have grasped this. They also haven't grasped how bad running such a tight loop is likely to be, nor do they understand what ctl-Z does.

Moving to a python based MIDI solution will remove the overhead from spawning a process, but the loop will never run as fast as they want it to. If it does, it'll use so much cpu time that nothing else will get a look in.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 1:48 pm

OutoftheBOTS wrote:
Fri Feb 23, 2018 9:44 pm
That's what the OP is doing. Just using an external process to send the message. There is no multi-processing going on.
The line of code

Code: Select all

 subprocess.call("./sendmidi dev f_midi pb " + pot0)
Does exactly that. It spawns a new multi process (not a new thread but a whole new process). This is the same as being on a windows computer and opening a new window and starting a new program running as a multi task (multi process).

So every time you execute subprocess.call you will be opening a new separate program as a multi task.

A quick google of python midi found many hits and the first that I clicked was this one https://mido.readthedocs.io/en/latest/

Something like this library will allow you to send you midi message from with in your python program without needing to open an external multi process
I think we're arguing semantics, which doesn't help the OP. Moving the MIDI functions inside the OP's script will improve things but I doubt the loop will ever run as fast as the OP desires.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

codGmer
Posts: 18
Joined: Wed Feb 07, 2018 7:48 am

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 2:15 pm

First of all, i dont need a loop if it is possible otherwise. I would like to get some help setting up the python script for sending midi because it is a lot more complex ofcourse. I dont get why you would call me 'they', you could answer me directly because it now feels like im being left out here. and i know what ctrl Z does but its just a finding that after doing that a couple of times every time that it really makes the script run like its supposed to. So please can we move on creating sending midi with python, a loop isnt nessecary. Or making a loop and then only send midi when the potmeter has changed. I really am thankfull for the help but im just learning it all. Im only familiar with c#.

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 2:56 pm

codGmer wrote:
Sat Feb 24, 2018 2:15 pm
First of all, i dont need a loop if it is possible otherwise. I would like to get some help setting up the python script for sending midi because it is a lot more complex ofcourse. I dont get why you would call me 'they', you could answer me directly because it now feels like im being left out here. and i know what ctrl Z does but its just a finding that after doing that a couple of times every time that it really makes the script run like its supposed to. So please can we move on creating sending midi with python, a loop isnt nessecary. Or making a loop and then only send midi when the potmeter has changed. I really am thankfull for the help but im just learning it all. Im only familiar with c#.
Appologies for "they" but I was responding to another poster's comments, not directly to you so it seemed apropriate.

As for ctr-Z, the gif you posted above suggests otherwise. Or at least that while you understand ctr-Z, you don't understand how to resume the suspended process.

Consider this pseudo code:

Code: Select all

read and store pot
send MIDI message
while True:
	read pot
	if pot value significantly different to stored value:
		send MIDI message
		store poit value
	pause for some amount of time
The time you pause for needs to be short enough that you get the response you want but not so short that it eats all the available cpu time.

Nothing above here is python specific.

You'll have to use a loop as the library you're using doesn't have a callback on change function.

To get the magnitude of the change between the two pot readings try this python snippet:

Code: Select all

change = abs(old - new)
You can then test as follows:

Code: Select all

if change > some_value:
EDIT:
The downside of this approach is that instead of having a continous range of values sent to MIDI, you'll only see changes in steps. If your minimu change is 10, your MIDI device will only see values of 10, 20, 30, etc

Give me some time and I'll post a possible approach that avoids this.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 4:48 pm

OK. consider this instead:

Code: Select all

read and store pot
send MIDI message
while True:
	read pot
	if pot value significantly different to stored value:
		send MIDI message
		store pot value
		pause for some amount of time
		read pot
		while new pot value != stored value
			send MIDI message
			store pot value
			pause for some amount of time
			read pot
	else
		pause for some amount of time

The outer loop waits for a significant change.
The inner loop then runs, sending MIDI messages until the pot has the same value on two passes through that loop.

Message won't be sent until the change exceeds your chosen threshold but once it does you should get continuous updates until it stops changing.

There's still one edge case to be aware of though: if the pot value is near either end (less than your chosen threshold) and is moved towards the nearest end the change won't ever be acted on as your code will never see a significant change in its value. This applies to my last post too.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

User avatar
thagrol
Posts: 931
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: Infinite loop checking potentiometer

Sat Feb 24, 2018 5:00 pm

A thought occurs that might go towards explaining the percieved speed up.

Python is an interpreted language not a compiled one, but user code is converted to python byte code the first time you run it. By default the converted code gets saved as a .pyc file. So for foo.py it saves foo.pyc.

The second and subsequent time you run it python will use the .pyc version even if you pass it the .py version on the command line. (well as long as the .py isn't newer than the .pyc). This skips a whole lot of processing so may be what you're seeing.

And recall what I said before about how you're using ctr-Z. You haven't been resuming a suspended process, you've been starting a new one.
Note to self: don't feed the trolls
If you believe "L'enfer, c'est les autres" (Hell is other people) have you considered that it may be of your own making?

Return to “Python”